tP comments dashboard

Sorted based on the number of comments given to others' PRs, but also showing comments on own PRs and other comments given.

[This page was last updated on Oct 07 2020]

Do change the USERGUIDE_URL in HelpWindow.java as well!

Switch to use logger

Switch to use logger, same for other 2 instances below

Switch to use logger

Remove

"Clears the item list"?

Would it be better to default quantity to 0 and description/location to none if user doesn't key them in? Currently they act as compulsory fields.

Javadocs

Extra lines

change address-book

Javadocs

change comment title

person -> item

Should these be locationIds and recipeIds?

Should these method names be getLocationIds and getRecipeIds?

use this format instead, replace with the fields we have

plural forms

extra lines

address book -> item list?

Javadocs

Make this comment appropriate pls 😃

Javadocs

the right side has less equal signs 😦

change address book to item list or something similar

same for this segment

change logger message

itemToAdd might be better

extra lines

item -> item and location

person -> item

extra lines

ItemList->RecipeList

item list file path

of recipes

recipe list file path

will fail checkstyle

item -> recipe

checkstyle

can consider shorter prefix

for clarity can change to "Recipe ID is out of range"

should this be {@code Item}?

catch specific exception

add comment above this line specifying that this is for the delr command

conform -> conform to

extra lines

this constructor might be misleading, would it be better to modify the existing one?

for instance

'''

if (!isDeleted) {

idCounter++;

}

'''

in the existing constructor might make it usable as an equivalent to this one

remove or change to logger statement

Name typo (?), img not updated

[stephentan]

change names in [ ]s to be consistent styling

img not updated

address book -> item/recipe

these steps as well

persons -> items/recipes

actual pictures pls 😃

should this be 3a and 4a?

recipe

standardise with README, use InvInator.jar or change README to inventoryinator.jar

add line back

via the issue tracker of this repository, with link to it

keep names consistent - full name or given name

rephrase to "what is going on under the hood"

should this be "deli stone" for the moment?

delr -n -i ?

should locations be included as well?

del -> deli

same for this line

delete -> deli/delr

mark as TODO for easier search

optionally provide a short intro on how we structured our personas (explain that our app will help transition the before scenario to the after scenario, etc.)

include option to use

'''

java -jar InvInator.java

'''

contacts -> items

mark as TODO

should we change to deli and delr for now?

should we split del -> deli + delr?

should we split del -> deli + delr here?

i think we should specify that they need to overwrite multiple files, since our storage for each class is in separate files

change titles for each of these files

Should this use the NOT_FOUND message instead? User does not need to know our implementation

'''

itemList.removeIf(x -> !x.getName().equals(productName) || x.isDeleted());

'''

in line 43 looks like it already ensures the item won't be deleted

Suggest to change phrasing to something like

"soft deletes recipes that contain deleted item as product or ingredient"

DeleteRecipeCommand -> DeleteItemCommand

use proper punctuation please

and all recipes associated with the item

please space the methods in this file

spacing

remove this line

@code item

spacing

proper punctuation please

spacing

use block comment

fix spacing in this file

spacing

space out these tests

re-add spaces in this file

fix spacing

spacing

more clear explanation needed

spacing

should these be containsMultipleWordsIgnoreCase?

remove line

is it possible to test results of command? eg. if no such item exists, or check that the item being shown is indeed the right item

Done in https://github.com/AY2021S1-CS2103T-F13-1/tp/pull/17

Done in https://github.com/AY2021S1-CS2103T-F13-1/tp/pull/16

Issue #30 opened as per review.

resolved by #31

I think we can remove this test case.

'''suggestion

    // Keywords match phone and email, but does not match name

'''

Should remove INVALID_ADDRESS and VALID_ADDRESS from constant declarations above as well.

Is there a particular reason as to why this test case was removed? Perhaps we can use a different invalid value instead of removing the entire test case.

Should probably remove the above

'''

@FXML

private Label address;

'''

as well.

'''suggestion

platform for tutors to handle all of their administrative matters.

'''

'''suggestion

Tutor's Pet displays your upcoming lessons so that you will never forget about them again.

'''

Not sure if this would sound more in line with the other points since the word 'your' was used in both the other.

'''suggestion

Tutor's Pet allows you to mark your students' attendance and participation for each lesson.

'''

Nice catch!

'''suggestion

public static final String MESSAGE_SUCCESS = "Listed all students.";

'''

Perhaps we can update the Tag examples to something that's more student-tutor relationship like. Maybe something like how the student is performing in class.

This line shouldn't change.

Similar here, would be good to update the example tags.

Would be good to update this test constant as well.

Command word should be in kebab case.

Command word should be in kebab case. Perhaps can change the title to "Listing all students within a class".

We should retain the generated table of contents instead of using simple bullet points.

I think the second add is redundant.

Ellipsis should remain outside of the square brackets since users need to repeat the prefix as well.

I don't think we are supporting the separation of CLASS_NAME from MODULE_CODE?

Need to remove the address field in this section as well and update the tag prefix.

Need to update tag prefix here as well.

I don't think name, telegram handle and email are optional fields.

We need to rethink the command syntax for this operation. The parsing of arguments will be troublesome in this format.

For now maybe we can leave this feature out of the UG.

Kind of weird I'm a Project Advisor in the project I'm working on. Maybe Lead Developer would make more sense, but I'll change that in my own AboutUs update later.

'''suggestion

'add''n/John Doe t/@johndoe e/johnd@example.com tag/student' : Adds a student named 'John Doe' to the application.

'''

The second example should include more than one 'tag' to show the possible multiplicities.

'''suggestion

e.g. '[tag/TAG]…' can be used as ' ' (i.e. 0 times), 'tag/student', 'tag/Average tag/TA Candidate' etc.

'''

'''suggestion

Format: 'add n/NAME t/TELEGRAM_HANDLE e/EMAIL [tag/TAG]…'

'''

'''suggestion

Format: 'edit INDEX [n/NAME] [t/TELEGRAM_HANDLE] [e/EMAIL] [tag/TAG]…'

'''

Not sure if this is the best implementation since the '/by' prefix will have no values associated with it when parsed by the 'ArgumentTokenizer'

'''suggestion

'list-students c/CS2103T Tutorial T10'

'''

'''suggestion

Add Student | 'add n/NAME t/TELEGRAM_HANDLE e/EMAIL [tag/TAG]…'
e.g., 'add n/John Doe t/@johndoe e/johnd@example.com tag/student'

'''

'''suggestion

Edit Student | 'edit INDEX [n/NAME] [t/TELEGRAM_HANDLE] [e/EMAIL] [tag/TAG]…'
e.g.,'edit 2 n/James Lee e/jameslee@example.com'

'''

'''suggestion

List Students in a Class | 'list-students c/CLASS_NAME'
e.g., 'list-students c/CS2103T Tutorial T10'

'''

'''suggestion

'''

'''suggestion

Links an existing student to an existing class in the application.

'''

'''suggestion

'list' followed by 'link s/1 c/2' links the 1st student in the application to the 2nd class in the application.
'find Betsy' followed by 'link s/1 c/2' links the 1st student in the results of the 'find' command to the 2nd class in the application.

'''

'''suggestion

Linking a student to a class: 'link'

'''

Should we update the rest of the use cases to use full stops as well?

Hmm, I think summary should remain after the detailed explanation, since it serves so summarise the above mentioned information.

In and A shouldn't be capitalised in the title.

I think we should retain the present participle form of the verb? The CS2101 set of slides for "Writing User Guide" also seems to favour retaining the present participle form of verbs, although it does not seem explicitly mentioned.

'''suggestion

3a. No students found.

'''

Would be good to mention that it is a message, otherwise might be confusing how to show an absence of something.

Should we keep it consistent and use delete instead of clear?

Technically Tutor's Pet can return more than one student found, so maybe it would be good to mention that it shows all matching students.

Applies to finding classes as well.

'''suggestion

Command overview

'''

'''suggestion

Clearing all students : 'clear-student'

'''

'''suggestion

Clearing all classes : 'clear-class'

'''

'''suggestion

| UC13 | Link a student to a class |

| UC14 | Unlink a student from a class |

'''

'''suggestion

Use case: UC14 - Unlink a student from a class

'''

'''suggestion

Use case: UC13 - Link a student to a class

'''

'''suggestion

| UC12 | Clear all classes |

| UC13 | Link a student to a class. |

| UC14 | Unlink a student from a class |

'''

'''suggestion

    assertParseFailure(parser, NAME_DESC_BOB + VALID_PHONE_BOB + EMAIL_DESC_BOB,

'''

'''suggestion

    assertParseFailure(parser, VALID_NAME_BOB + PHONE_DESC_BOB + EMAIL_DESC_BOB,

'''

'''suggestion

    assertParseFailure(parser, NAME_DESC_BOB + PHONE_DESC_BOB + VALID_EMAIL_BOB,

'''

'''suggestion

public static final String MESSAGE_SUCCESS = "All students in Tutor's Pet have been cleared!";

'''

Perhaps we can rename this to getAddStudentCommand(Student student)

'''suggestion

public void parseCommand_editStudent() throws Exception {

'''

'''suggestion

public void parseCommand_deleteStudent() throws Exception {

'''

'''suggestion

public void parseCommand_addStudent() throws Exception {

'''

'''suggestion

public void parseCommand_clearStudent() throws Exception {

'''

'''suggestion

public void parseCommand_findStudent() throws Exception {

'''

'''suggestion

public void parse_validArgs_returnsFindStudentCommand() {

'''

'''suggestion

public void parse_validArgs_returnsDeleteStudentCommand() {

'''

I don't think we should allow the explicit setting or getting of UUID in EditStudentDescriptor since it would then no longer be editing the same student.

The editedUuid should always be that of the studentToEdit.

I think it would be good to set a default UUID for each student in the tests and not rely on randomly generated data. This way it would be more predictable and testable.

I don't think there is a need for EditStudentDescriptor to have a uuid field.

'''suggestion

    requireAllNonNull(uuid, name, phone, email, tags);

'''

It would be good to edit the constructors in the TypicalStudents file as well to ensure the test constants are truly identical.

'''suggestion

'''

'''suggestion

private static ModuleClass createEditedModuleClass(ModuleClass moduleClassToEdit,

        EditModuleClassDescriptor editModuleClassDescriptor) {

'''

'''suggestion

Parses input arguments and create a new EditModuleClassCommand object.

'''

'''suggestion

 * Parses {@code userInput} into a {@code StudentNameContainsKeywordsPredicate}.

'''

There's quite a bit of overlap here, would be good to deduplicate into:

'''suggestion

public static final Index INDEX_FIRST_ITEM= Index.fromOneBased(1);

public static final Index INDEX_SECOND_ITEM = Index.fromOneBased(2);

public static final Index INDEX_THIRD_ITEM = Index.fromOneBased(3);

'''

'''suggestion

A utility class for ModuleClass.

'''

Seeing this template always makes me feel like they have already foreshadowed that we should do undo/redo features.

'''suggestion

Contains integration tests (interaction with the Model) and unit tests for

'''

'''suggestion

A UI component that displays information of a {@code ModuleClass}.

'''

Since we seem to be standardising to capitalise UI.

'''suggestion

// Independent UI parts residing in this UI container

'''

It should be A UI because in both user interface and UI the word/abbreviation is pronounced as though it starts with the consonant y.

'''suggestion

A UI component that displays information of a {@code Student}.

'''

'''suggestion

-fx-background-color: transparent, #274156, transparent, #274156;

'''

I think it would be best to define the return type as Label since we do in fact return a Label.

'''suggestion

 * Converts this Jackson-friendly adapted class object into the model's {@code ModuleClass} object.

'''

'''suggestion

 * Converts a given {@code UUID} into this class for Jackson use.

'''

'''suggestion

 * Converts this Jackson-friendly adapted UUID object into the model's {@code UUID} object.

'''

'''suggestion

 * @throws IllegalValueException if adapted UUID is null.

'''

I think it would be a good idea to introduce some checks for invalid UUIDs since the user can go into the json file to edit entries manually.

I would agree with @junlong4321 on this, it would be good to isolate any possible failure to just students.

While in invalidClassTutorsPet.json, students would be useful in the future when we implement validation for students who are registered in classes.

I agree with @ruixuantan. It would be safer since users can head into the json save file and modify its contents manually.

I think if we are fine with breaking the abstraction barrier, in some sense we already have since we are dealing with UUID objects instead of strings, then it is okay to change all references to studentUuids instead, including in the model.

Naming here might be a bit confusing since uuid is a object type itself.

'''suggestion

private final String uuidString;

'''

'''suggestion

 * Constructs a {@code JsonAdaptedModuleClass} with the given class details.

'''

'''suggestion

 * Converts a given {@code ModuleClass} into a {@code JsonAdaptedModuleClass} for Jackson use.

'''

'''suggestion

 * @throws IllegalValueException if there were any data constraints violated in the adapted class.

'''

'''suggestion

 * Creates a {@code ModuleClassBuilder} with the default {@code Name} and empty {@code studentUuids} list.

'''

'''suggestion

public static final UUID ALICE_UUID = ALICE.getUuid();

public static final UUID BENSON_UUID = BENSON.getUuid();

'''

Can these two methods be made private?

I would advise against adding the class names as Tags since it might confuse our first time users into thinking that linking students to classes would automatically add the classes as Tags.

Perhaps it would be a better idea to declare the students and classes as static members and then have the two methods return a list of the static members.

Also, I think the two getter methods can be made private.

'''suggestion

    // different keyword -> returns false

'''

'''suggestion

 *

 * @throws ParseException if the user input does not conform the expected format.

'''

NIT: It might be a good idea to leave a class or two for manual adding when testing.

nit

'''suggestion

    FindModuleClassCommand expectedFindModuleClassCommand =

            new FindModuleClassCommand(new NameContainsKeywordsPredicate<>(Arrays.asList("CS1101S", "Tutorial")));



    // no leading and trailing whitespaces

    assertParseSuccess(parser, "CS1101S Tutorial", expectedFindModuleClassCommand);

'''

'''suggestion

 * Additionally, removes all {@code Student UUID}s in each {@code ModuleClass}.

'''

'''suggestion

/**

 * Removes all {@code Student}s from the student manager.

 * Also removes all {@code Student UUID}s from each {@code ModuleClass}.

 */

'''

Perhaps it might be a good idea to have the same name for both methods (in Model and in TutorsPet)?

Perhaps '{@code Student UUID}s' would be more accurate since '{@code studentUuids}' refers to the list itself rather than its contents.

'''suggestion

/**

 * Removes all {@code Student UUID}s from every {@code ModuleClass} in the class list.

 */

'''

Is there any particular reason why we choose ClearModuleClassCommand as the different type as opposed to some other primitive type like an integer?

'''suggestion

    model.deleteAllModuleClasses();

'''

'''suggestion

private static final int NUMBER_OF_COLOURS = COLOURS.length;

'''

Should we be using the American spelling of Colour instead?

I think we should retain the name listOfTags or tagList instead? Although the field was declared as static final, it is not exactly a constant in essence since the contents of the list can change.

I think it would be wise to follow the following categorisation of constants as given by the excerpt below from the Google Style Guide.

'''suggestion

    requireNonNull(toCheck);



    return internalList.stream().anyMatch(toCheck::hasSameUuid);

'''

'''suggestion

    requireNonNull(student);



    return students.containsUuid(student);

'''

Instead of reading students once again, perhaps we may want to use the existing information stored within tutorsPet instead?

We can also document this precondition in the JavaDoc to state that the tutorsPet passed in should have its students loaded prior.

Just wondering, is this "feature" extended to the native UUID stored in each JsonAdaptedStudent as well?

'''suggestion

 * If Tutor's Pet encounters duplicate {@code Student UUID}s in a class, it will not load

 * duplicate {@code UUID}s into the model. Hence, Tutor's Pet should still boot up successfully.

'''

'''suggestion

 * Ensures that Tutor's Pet will not be able to boot up given an incomplete {@code UUID}.

'''

'''suggestion

 * Ensures that Tutor's Pet will not be able to boot up although Java tries

 * to pad missing {@code UUID} digits in broken {@code UUID}s with zeros.

'''

'''suggestion

 * Prevents Tutor's Pet from booting up if two or more {@code Student}s are found with the same {@code UUID}.

'''

'''suggestion "Invalid student(s) found in class(es)."; '''

In view of the change, I would recommend changing the test case to remove a student that was not previously part of any class. This way, we would only be changing the student list and would be a better representation of the test case.

TIL, didn't know that.

Quite interesting explanation here also: English StackExchange

The JavaDoc was adapted from an equivalent JavaDoc in UniqueStudentList.

I would be more inclined to retain both in their current expressions.

This JavaDoc was directly adapted from a corresponding JavaDoc in the existing UniqueStudentList class as well. As such, I would be more inclined to retain the current expression since it is consistent with existing code.

The backing list refers to the internalList while unmodifiable means that any attempted modifications on the list would result in an UnsupportedOperationException being thrown.

'''suggestion

    // workaround as storage functionality for ModuleClasses has not been implemented

'''

'''suggestion

    // workaround as storage functionality for ModuleClasses has not been implemented

'''

Agree with @junlong4321 for consistency.

This JavaDoc was directly adapted from a corresponding JavaDoc in the existing UniqueStudentList class, so I would be more inclined to retain the current expression since it is consistent with existing code.

'''suggestion

'''

As these informal list points are not complete sentences and are fragments, I would be more inclined to leave the full stop out?

Oops, that slipped through my manual search and replace.

I think for this case, it would be okay to not include an empty line above the comment since it is the first line in the method body. It will also be more in line with existing code.

Good idea, added in!

Resolved instead by changing to lowercase throughout, more in line with comments found above.

Can you rebase and then should be good to go.

Not sure if we need to get approval before we merge this in since we are trying to use a new module?

This seems to be missing the saving of UUIDs to local storage, is that planned for a separate PR?

Closed with #61.

Closed with #62.

Resolved in #68.

Closed with #55.

Should we standardize comments? One possible style:

Separate-line comment with whitespace, singular verb, and uppercase 1st character.

'''

// Parses user input...

Command command = addressBookParser.parseCommand(commandText);

'''

Same-line comment with whitespace, singular verb, and lowercase 1st character.

'''

Command command = addressBookParser.parseCommand(commandText); // parses user input...

'''

We could follow any other style too. Just thought it might be better for everyone to stick to 1 for consistency.

Sure, we can restore this when we complete EditCommand.

Really like the regex here. It is simple and effective.

I know this is a bit late, but do you think we should change AddPersonCommand to AddPatientCommand?

I think our Person refers specifically to Patient since we have the periodOfStay field. If we are adding a Staff class in the future, it may be a little misleading since Staff is a Person too.

What do you think?

Since we are using Patient now, maybe we can rename some of these variables?

Perhaps from MESSAGE_INVALID_PERSON_DISPLAYED_INDEX to MESSAGE_INVALID_PATIENT_DISPLAYED_NAME.

Also, do you think we should change our usage of "person" to "patient"? 🤔

i.e. "The patient name..." instead.

I like the use of guard clauses in this method. Makes the code much cleaner 😀

Great work on writing the unit tests! For v1.1, we might not need it but getting it done earlier is a nice bonus.

Maybe it could be invalidPatientName instead? I know it might be a little troublesome to change all references to Person to Patient. I can help with that if you would like.

For separate-line comments, do you think we should keep the first character in uppercase?

The Java coding standard we are using does not explicitly mention it but seems to follow that. I think comments that start with keywords may not need to be capitalized though (e.g. null).

I think "list of patient/all patients that match the specified criteria" may be clearer?

Great use of Optional here!

Do you think an Enum may be preferable here since there are a limited number of possible values?

Using 'int' is not very scalable. If we have 10 different search conditions, we would need 10 'int', and it can be hard to keep track of these variables.

Perhaps we can declare a nested Enum:

'''

private enum SearchCondition {

SEARCH_BY_NAME.

SEARCH_BY_TEMPERATURE,

SEARCH_CONDITION_INVALID; // no condition or multiple conditions given

}

'''

If you would like to use 'int', maybe it would be better to make them static and change the variable names to indicate they are constants. E.g.

'''

private static final int SEARCH_BY_NAME = 1;

'''

Personally, I think Enum might be neater. 😄

Maybe we can add a space here? "TEMPERATURE RANGE " instead of "TEMPERATURRANGE".

This text will be displayed to the user, and the former may be easier to read?

Maybe one private method for each search condition? That would be great.

I'm not too sure but I think the execution will not reach this return statement? If that is the case, I think we can throw a CommandException instead of returning null? Returning null here may cause a NullPointerException somewhere else.

Perhaps we can rename this method to confirmSearchConditions or determineSearchCriteria? area may not be very clear that we are referring to the search conditions.

JavaDoc comments here are really useful to understand the purpose of the nested class. Great work 👍

@itssodium Could you check whether these changes are correct?

If I am not wrong, the Covigent part is the latest edit. It might have been overwritten by accident.

Would you be able to undo the deletion of this file? DateTimeUtil.java was recently added to manage dates and times.

Perhaps we could name this AddRoomCommand instead?

AddNumberOfRoomsCommand seems a little verbose since the number of rooms is implied, though this is a matter of preference.

If you like AddNumberOfRoomsCommand better, let's keep that.

Similarly, perhaps we could rename the command to addroom.

I think it's great that you refactored the code used for I/O. I/O should be abstracted if possible (SRP) since this class mainly handles the adding of the room.

Maybe we can follow the convention here? For messages, Address Book Level 3 follows this convention: MESSAGE_ERROR or MESSAGE_SUCCESS. We could use MESSAGE_NUMBER_OF_ROOMS_UNDEFINED or something along those lines here for consistency.

Would be good to add a comment here if the -1 means something.

Similarly, we can follow the conventions for messages here.

It is less about whether the user will enter a negative number, and more about how we should secure our application.

Personally, I feel that it is good if we can handle as many exceptional cases (sometimes called edge cases) as possible. Without proper handling, anyone can crash the app simply by entering a negative number. It can be annoying for the user if they accidentally type in a negative number and the app just stops working.

Besides, near the end of the semester, our application will be manually tested for bugs. I am fairly sure the testers will try to use negative numbers as inputs. If they can cause the application to crash, they will flag the problem as a bug and deduct our marks for it. Let's do our best to stop that from happening! 😄

May I ask what is the reason for naming the class RoomBook instead of RoomList or RoomQueue? I feel that Book does not explain what the class does.

Would it not be possible to use an ArrayList<Room>?

I think it is easier to understand if you iterate through all the Room objects in a loop and call an isEmpty() method to determine which Room is empty.

Performance-wise, I understand PriorityQueue may be better but we are sacrificing code clarity for performance.

Shouldn't Room contain an ArrayList<Task>?

@itssodium Would you be able to check this?

Do you mean it will be used for allocating the Patient to the Room?

Okay, leave this part to me. I will add in the TaskList.

Would it be possible to use Optional<Patient> here? While it is true that the Room can have no Patient, it is best to avoid null.

Great that you have a separate class for storage!

I think that is probably the temporary files used for testing? 🤣 Shall we rename the test files?

Yup, Address Book Level 3 has a convention for the names of test cases. Maybe we can follow that next time?

Ohh okay I follow your train of thoughts now. For adding Patient to Room, I think we should be more explicit? Maybe something like AddPatientToRoom.

I think you can use AddRoom for this.

May I check if URI is used here? I think path is a String and URI may not be needed here?

I think it would be good if you could leave a comment to explain the use of the nr and ro options!

Would it be possible to split this test into smaller units? It is currently longer than 30 lines.

Perhaps this part

'''

    rooms = new PriorityQueue<>();

    for (int i = 0; i < 10; i++) {

        Room room = new Room(i + 1);

        if (i % 2 == 0) {

            room.setOccupied(true);

        }

        rooms.add(room);

        roomsInArray[i] = room;

    }

    roomList = new RoomList(rooms, roomsInArray, 10);

    numberOfRooms = Paths.get("numberOfRooms");

    roomsOccupied = Paths.get("roomsOccupied");

    roomOccupancyStorage = new RoomOccupancyStorage(numberOfRooms, roomsOccupied);

    roomOccupancyStorage.saveNumberOfRooms(roomList, numberOfRooms);

    roomOccupancyStorage.saveOccupiedRooms(roomList, roomsOccupied);

    roomList1 = roomOccupancyStorage.readOnlyRoomOccupancy();

    assertEquals(roomList, roomList1);

'''

can be in a separate test?

I think addRooms here refer to allocating a Patient to a Room? Most likely, this test would be in a separate class so maybe we can remove it first?

Don't worry, I can handle this part. 😄 I will have to integrate the TaskList into Room to get my part working anyway.

I think it would be good to leave an explanation of why numberOfRooms is initialized to -1.

Perhaps the messages here can be moved to another class? Ideally, we can avoid adding constants to this class since the messages are stored in seedu.address.commons.core.Messages instead. Maybe look into putting your messages there too?

I think IntelliJ might have changed this to wildcard imports? Maybe we can revert this?

Do you think we should keep the indentation consistent? For *.fxml files, maybe we can use 2 or 4 spaces (not sure what the original is).

I think it would be patients here. Very minor grammatical issue though 😄

I like how there is an order for the different types of entities (patients followed by rooms followed by miscellaneous). Maybe in the future, we can a header to each entity to further organize the content of our user guide? E.g.

'''

3.1 Command Format

3.2 Patients

 3.2.1 [Add a patient: 'addpatient'](#32-add-a-patient-addpatient)<br cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf">

// ...

'''

Do you think we should standardize this? Not sure if it is as important in the JavaDocs because it is understandable, but what about the user guide?

Should we refer to the application as the app, the application, or Covigent?

Thank you for noticing and changing this! 😄

Because isSamePatient(...) uses name, age, and phone number as criteria to detect duplicate Patient in a list, will this not pose a problem when deleting? It is possible to have more than 1 Patient with the same name after all. In that case, only the first matching Patient is deleted.

I think it may be a little strange that the user cannot select which Patient to delete if they share the same name. I am not sure about the optimal way to solve this problem. Would deleting by index be better?

Good job noticing the bug here! 😄

Maybe this can be renamed to indicate that an invalid search criterion has been provided. searchPatient does not really explain which aspect is being tested.

Something like execute_searchPatientInvalidSearchCriteria_throwsCommandException() may be good?

I think it would be good to mention something along the lines of how the command replaces the current number of rooms with the newly specified value. Also, whether the data in the current rooms will be migrated or reset.

We can always improve on the user guide in the future though, so maybe we can KIV? 😄

Since there are multiple files being checked, maybe we can include which data file is not in the correct format in the warning.

The same goes for the other warnings.

Maybe we can keep this statement in a single line such that it looks even neater? It has fewer than 110 characters and can fit in one line!

Perhaps we can remove code that is commented out. If we merge this, we may forget to remove it in the future. Also, commented out code seems like regular comments and may be difficult to locate in a large codebase.

Great work with the hashing!

May I ask why the 31 is needed here?

I think maybe we can make this more general and apply it all the other *List classes (UniquePatientList, RoomList, TaskList). Otherwise, I think the interface may not be needed?

Possibly ReadOnlyList<T>? We can do either:

Include all methods such as add, delete, etc. (much more work because we have to rename all methods to share a common name).
Include just the method to obtain a read-only list (easier).

Maybe we can add a TODO here to indicate that in the future, we should set the application default to having a few rooms with patients and tasks?

Although ObservableList and PriorityQueue maintain the same rooms, for safety would it be better to include a comparison for the ObservableList too?

The condition for this is rooms != null && roomList.rooms != null but I think neither the PriorityQueue nor ObservableList can be null because of the default value, right?

In that case, can you not just return false if any of the 2 PriorityQueue and 2 ObservableList are null?

Instead of tracking numOfRooms in a variable, would it be possible to just make use of the size of the ObservableList? Maybe include a method to get size (similar to the other *List classes).

This would reduce the complexity of the class, especially when writing the equals(...) or hashCode() method since there is one fewer variable to manage.

'@JsonProperty' tells the Jackson ObjectMapper to map the JSON property name to the annotated Java field's name so we end up with this:

'''

"room": {

"roomNumber": value

"isOccupied": value

 //...

'''

For consistency with 'JsonAdaptedPerson', perhaps we can keep it the same as the variable name (i.e. roomNumber and isOccupied)? We would have

'''

public JsonAdaptedRoom(@JsonProperty("roomNumber") int roomNumber,

    @JsonProperty("isOccupied") boolean isOccupied) {

//...

'''

We can add a TODO here since we are not using the Patient and Task in this class yet.

Consistent @JsonProperty here! Variable name should be rooms.

Good job with switching to temp folders! 😊

Maybe we can import java.util.Optional directly?

I think if we are not using this class currently, we can remove it 1st?

I will add this when I pull your changes 👍

Okay, noted on this. I will make the change. Thanks!

Agreed! Let's remove the additional fields.

Yes, right you are! I will change this.

Interestingly, yyyyMd does not work.

Consider the date "12 Jan 2020", for instance. With yyyyMd, it would be "2020112". But this string is ambiguous. Are we referring to "2 Nov 2020" or "12 Jan 2020"?

If we want to use yyyyMd, we would need a delimiter (e.g. yyyy-M-d). I decided against using the hyphen because it doesn't read as well when it is a date range.

Actually, yeah. It is probably not needed for an MVP.

The rationale behind adding DateTimeCreated is to allow the user to filter tasks with creation date as a criterion. For example, in Slack, users can see when the task is created. It is helpful when the user wants to query what tasks were created yesterday or within the last few days.

Right now, the plan is for the user to click on a Room in order to view all tasks assigned to it. There is no separate tab for the users to manage tasks (we should probably have this to show user which tasks from which rooms are due?). In the future, when we implement reminders or a search for tasks, DateTimeCreated might be more useful.

I think I will remove this from the MVP. Unit testing for this class also requires more work because we would need another layer of abstraction to handle and control the date-time instead of using LocalDateTime.now().

Thoughts on this?

Okay!

Nope, it is in an entirely different file. That said, I wonder if it will be confusing for the user?

No problem!

I think p/ is good 😄 We can try to keep it as short and sweet as possible since that's easier to remember.

@itssodium would you like to close this PR? I think we could keep the other one instead?

Good work! We will have to correct the CheckStyle problems in order to merge. Would you be able to change the order of imports?

We have decided to close this issue. Don't worry about creating the pull request from master.

For future pull requests, remember that every new feature should be done in a separate branch!

Task models are added 1st. Will be integrated with Room in v1.2.

While not ideal, I decided to force push to my own repo in order to squash the commits that contained only minor changes for CheckStyle compliance.

I will be more careful when pushing to my repo in the future.

Overall, clean and neat code! Believe you haven't integrated the command into the code yet but seems like good support for your command for now. One thing though, I am not sure why you want to have a DateTimeCreated for task? Anyway, LGTM!

Haha, yeah I set up the PR to update everyone with my progress. The integration is not complete yet. I will request for more reviews when the integration is done.

To fix your addressbook and let it show its contacts, follow these steps:

Go to your data folder

Open up addressbook.json

In the second line, change "persons" to "patients"

I recommend deleting data/addressbook.json if you have not added any custom data. Upon restarting the app, the file should be regenerated.

Additionally, the logic in 'readAndSaveRoomList' unit tests may be difficult to follow without comments. Do you think it would be possible to add

'''

// Save in new file and read back

RoomOccupancyStorage roomOccupancyStorage = new RoomOccupancyStorage(numberOfRooms, roomsOccupied);

// ...

'''

to indicate that you are saving and loading the file for testing?

There is also some code duplication in the 'readAndSaveRoomList' tests, which we can consider refactoring into private methods.

I removed the link to #58 because we haven't actually displayed the Patient and Task details for each room. We can definitely merge 1st though.

Rebased to avoid additional merge commit.

lgtm, good job! However, the pr is super long, would it be better to like split it up in the future? eg. do the tasklist/task class and merge it first. then the addTask command and then merge it?

Totally agree with this. Ideally, I think a PR should not exceed 500 lines. It is difficult to review the PR when it is that long. I originally wanted to split this as well. Will definitely do so in the future! 👍

I think "the filename of the profile photo should be doc/images/githbub_username_in_lower_case.png" - Week 7 Point 2 in Project

Might wanna consider team/samlsm instead

Missing space before 4a.

Remove extra space

Missing "Use case ends."

Inconsistent comma, (+ EMAIL_DESC_BOB,)

//// student-related tests may work better here instead of Student, since we also have //// moduleClass-related tests

Extra space

See if its possible to trim down this part. I took a couple of tries before I understood what was going on

The {@code ModuleClass} must not exist in the current list

Don't quite understand this. Specifically, don't understand what is a backing list and what is meant by unmodifiable

'''suggestion

/** Returns an unmodifiable view of the filtered 

 * {@code ModuleClass} list.

 */

'''

'''suggestion

// student-related constants

'''

'''suggestion

// moduleClass-related constants

'''

Need full stop for this comment

Comments start with lower letter + no full stops

'''suggestion

    // workaround as storage functionality for ModuleClasses has not been implemented

'''

Ok lets retain it in that case

Missing space

'''suggestion

        + PREFIX_TELEGRAM + "johnDO3 "

'''

Consider keeping the previous tag set? Because its more of an app to track students rather than keep address contacts.

I think the tagset got overwritten. Saw that you merged the master branch into your branch

Might be good if we remove the telegram prefix, since user has to type @ for email. So we might want to keep the design consistent by making them type @ for telegram handle

An alternative would be to update both the UG and DG to reflect the telegram handle changes.

I personally would go for the former than latter. How about the rest?

Any reasons why "student" was removed?

Extra white space

Any reasons for removing this white space?

Resolved by sticking to using TELEGRAM_PREFIX = "@"

Any reasons for removing this white space?

Resolved by adding back "student" in command

'''suggestion

 * @param index Index of the class in the filtered class list to edit.

'''

'''suggestion

 * @param editModuleClassDescriptor Details to edit the class with.

'''

'''suggestion

    // short circuit if same object

'''

'''suggestion

    // instanceof handles nulls

'''

'''suggestion

    // state check

'''

'''suggestion

 * @throws ParseException If the user input does not conform the expected format.

'''

I think the full stop got removed for some reasons.

My current updated code base has a full stop for this comment

'''suggestion

Parses input arguments and creates a new FindStudentCommand object.

'''

@throws ParseException If the user input does not conform the expected format.

'''suggestion

        || (other instanceof ModuleNameContainsKeywordsPredicate // handles null)

'''

start with lower case, e.g

'''suggestion

    // one keyword

'''

'''suggestion

 * Returns an {@code EditModuleClassDescriptor} with fields containing {@code moduleClass}'s details.

'''

Can you help center the fencing for the table?

Can you help organise/center the fencing "|" for the userguide table as well? I remembered centering it awhile back during v1.1 but seems like some of the fences got out of position again

'''suggestion

Shows a list of all students and all classes in the application.

'''

Might want to consider putting this after DeleteModuleClassCommand.COMMAND_WORD but before LinkCommand.COMMAND_WORD to maintain a fixed action sequence

"3" seems like a magic number across the test script. We might want to consider abstracting it into a variable in a separate PR

I think we should use Color since the naming before the change was Color

I agree with Dexter on this

'''suggestion

 * Deletes the given {@code Student} and the {@code Student}'s {@code UUID} in all {@code ModuleClass}es.

'''

'''suggestion

'''

'''suggestion

'''

'''suggestion

 *  Deletes {@code key} from this {@code TutorsPet} and also the {@code UUID} of {@code Student} from all {@code ModuleClass}es.

'''

Just to clarify, the reason why you create a new hashset is because the set returned by getStudentUuids() is immutable?

'''suggestion

    // manually remove UUID

'''

Is this change because if a student is deleted, then the associated student in ModuleClass is removed as well?

Resolved by removing MODULE_CODE

Resolved by removing [] for all fields within add apart from [tag/TAG]

Resolved by updating line 58 to

'''

e.g. '[tag/TAG]…' can be used as ' ' (i.e. 0 times), 'tag/student', 'tag/TA' etc.

'''

Resolved by adding in commit suggestion

'''

List Students in Class | 'list-students /by n/CLASS_NAME'
e.g., 'list-students /by n/CS2103T Tutorial T10'

'''

Resolved by changing clear class to "clear-class"

Resolved by changing list students to "list-students", and title to "Listing all students within a class"

Resolved by retaining {:toc}

Resolved by removing redundant add

Resolved by moving ellipsis outside of square brackets

Resolved by removing address field and updating tag prefix from /t to /tag

Ok i won't be touching it in that case

Added the tags, used tag/average and tag/TA candidate to keep formatting consistent

I think it'd be better if the summary comes before the detailed explanation. As a user i wouldn't want to scroll downwards if i just want to reference the commands. What do the rest think?

I thought of that, but the issue is that the formatting will not be standardized across the table and commands. I feel that perhaps its better to caps everything so that we standardize our documentation

Issue is that the formatting will not be standardized across the table and commands. I feel that perhaps its better if we follow the actions used in the command summary?

Changed Command summary to Command list

Resolved by rewording expression to show that Tutor's Pet can return more than one user found

Will keep clear instead of changing to delete

Ok lets keep the previous

Will be keeping line 155 instead

To change to requireAllNonNull(uuid, name, phone, email, tags);

Good catch, thxs, no point editing UUID so no point adding UUID into EditStudentDescriptor.

Resolved by removing setUuid() and getUuid()

Resolved by changing line 93 to UUID updatedUuid = studentToEdit.getUuid();

To add a DEFAULT_UUID in StudentBuilder.java and convert it to a UUID for usage instead of generating a random UUID for testing

Resolved by removing UUID field

Resolved by specifically adding Uuids into TypicalStudents

RIP, forgot to remove sneaky boi

Added the following :

JsonAdaptedStudent.java

'''

    if (uuid == null) {

        throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid"));

    }

'''

JsonAdaptedStudentTest.java

'''

@Test

public void toModelType_invalidUuid_throwsIllegalValueException() {

    JsonAdaptedStudent student =

            new JsonAdaptedStudent(null, VALID_NAME, VALID_PHONE, VALID_EMAIL, VALID_TAGS);

    String expectedMessage = String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid");

    assertThrows(IllegalValueException.class, expectedMessage, student::toModelType);

}

'''

Since UUID is a built-in java class, instead of doing something like '''throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, Name.class.getSimpleName()));''' , i opted for '''throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid"));'''

Possible, but the json "studentIds" in the json file will be changed to "studentUuids". Which one do you guys prefer?

I initially added a class entry, but then eventually removed them as I wanted to isolate the test cases better (Since this json file is more to test for invalidstudent rather than invalidclass.) Any thoughts?

Currently since we are using UUID.randomUUID(), the edge case that could potentially happen is a null UUID rather than that of a UUID that is not specified properly, unless the user decides to edit the uuid in the json file to a smaller uuid string. Hence i decided to only test for toModelType_nullStudentIds_throwsIllegalValueException()

Any thoughts on this?

Was thinking that a guard clause would be sufficient (Since its likely the case that a uuid is either well defined (by using Java's UUID.randomUUID(), or null))

Any thoughts on whether a try catch is needed here? Will include one if needed

Thats a good idea. I'll pull information from ALICE directly and remove the TODO comment

Resolved by keeping status quo for invalidClassTutorsPet.json (ie no changes)

Resolved by adopting suggested change

Resolved by pulling information from ALICE directly and removing TODO comment

Resolved by refactoring all occurrences of studentIds to studentUuids, including the studentIds field in model ModuleClass.java

Resolved by abstracting code inside toModelType() into two smaller methods.

Resolved by adding try catch block

Resolved by introducing checks for invalid UUIDs

Yes, it applies across all UUIDs so long they are not invalid

An example of an invalid UUID is "fffa3023-7d89-426b-ba01-" // No uuid values after dash

In contrast, a valid uuid is "fffa3023-7d89-426b-ba01-d45eaa" // Missing values after d45eaa are padded with zeros

Resolved by using existing information from ObservableList in tutorsPet

Completed

This seems to be missing the saving of UUIDs to local storage, is that planned for a separate PR?

To implement saving of UUIDs to local storage

Mostly looks good to me, just need some minor changes.

Could you also add a test case to ensure that 'EditStudentDescriptor' does not change the UUID of a student?

I think this part of EditStudentDescripterTest.java factors in that UUID isn't changed? Otherwise it will return false if the UUID changes

'''

public class EditStudentDescriptorTest {

@Test

public void equals() {

    // same values -> returns true

    EditStudentDescriptor descriptorWithSameValues = new EditStudentCommand.EditStudentDescriptor(DESC_AMY);

    assertTrue(DESC_AMY.equals(descriptorWithSameValues))

'''

Not sure if we need to get approval before we merge this in since we are trying to use a new module?

Module has been removed (Last checked 26/09/2020)

Looks great! But like what Dexter said, I am not sure whether we need to get permission first.

Module has been removed

@ypinhsuan can yours work? my one works fine

Decided not to implement UUID equality check as it may risk introducing a lot of bugs into the code

New feature added does not correspond to the feature you were assigned. Possible typo?

Examples provided not changed to match the changed feature.

User command should be just "list" instead of "list 2" to fit the explanation fo the command. Possible typo?

Maybe changing it to "displays all your assignments and lessons for the next 2 weeks" would be more succinct?

How about "displays all your lessons and assignments for the next 2 weeks (including the current week)"?

Looks good!

@printinghelloworld sounds good 😃

Looks good 😃 A minor nitpick is that you may want to consider removing point number 3 ("ASM retrieves lesson data from NUSMods API") as according to the textbook, use cases only describe the externally visible behavior, not internal details, of a system.

Similar to the above comment, maybe it would be better to change the phrasing to describe how the ASM displays the lessons from the newly imported timetable

Maybe including the time the assignment is due in the deadline would be better?

E.g: n/Lab report 3 d/23/04/2020 1230 mod/CS2100

Since we have some optional fields as well, maybe it would be clearer to the user if we changed the description given in AB3 to match our project?

I was suggesting to keep the Tip section and change the description to "You can use the remind tag to set reminders for the assignment you want to add instead of using the remind command after adding the assignment" or something along those lines.

Currently, module code can accept the same string format address in AB3. Perhaps consider changing it the VALIDATION_REGEX to match the format of module codes as well?

Testing of new ModuleCode field may be more accurate if the input was changed to match the module code format.

INVALID_ADDRESS_DESC should be INVALID_MODULE_CODE_DESC for consistency 😃

Similar to the above comment, VALID_ADDRESS_AMY should be VALID_MODULE_CODE_AMY.

Similar to VALID_ADDRESS_AMY comment.

Name of method still refers to address instead of moduleCode. Possible typo?

Could consider changing the test cases to test for valid module codes 😃

According to the 2103T textbook, the suggested guideline for code quality is to break-line after the bracket instead of in the middle of an instantiation.

E.g:

JsonAdaptedPerson person = new JsonAdaptedPerson(

VALID_NAME, VALID_PHONE, VALID_EMAIL, null, VALID_TAGS);

The comment describing the test still refers to address field instead of module code field.

Similar to other comments, the comment describing the test still contains address.

Comments still refer to address. But it is just a minor nitpick 😃

Similar to other comments 😃

This line can be removed 😃

Comment still refers to address instead of module code

Maybe could do more testing to ensure that the regex works as it's supposed to? You can consider testing for modules codes with no alphabets at the start ("1010S"), modules with no numbers ("GER"), modules that begin with more than 3 alphabets ("ABCD1000") etc

Comment still refers to address field.

Similar to other comments relating to address comments 😃

The comment describing the email test is not deleted.

The comment for this test still contains 'email'

yup

This test case seems to still have references to email.

Comment still references email.

Comments for this field use 'persons' instead of 'assignments'. Be sure to check the comments as well 😃

Similar to the other comment, the comments for the field use 'persons' instead of 'assignments'

Similar to the other comment, the comments for the method use 'persons' instead of 'assignments'. Same for the equals method below this method 😃

Similar to the other comments, the comments use 'persons' instead of 'assignments'

Similar to the other comment, the comments for the method and the string parameter at line 9 use 'persons' instead of 'assignments'.

Similar to the other comments, the comments use 'persons' instead of 'assignments'.

Similar to the other comments, the comments use 'persons' instead of 'assignments'

Nice test cases 😃 You may want to consider leaving a space between some parts of the code to make it more readable (e.g leaving a space between lines 79 and 80 and leaving another space between lines 81 and 82)

Similar to the previous comment on improving readability 😃

Similar to the other comments, the comments use 'persons' instead of 'assignments'

According to the CS2103T textbook, the convention for the indentation for wrapped lines should be 8 spaces.

Following the CS2103T convention, you may want to consider changing the indentation to match the one in red 😃

You may want to consider leaving a blank line between some lines to improve readability and code quality (E.g leaving a space between lines 82-83 and lines 84-84). You can refer to the screenshot of the CS2103T coding conventions below 😃

Similar to the comment above on readability 😃 You may want to consider applying the same thing to the other test cases in this class

JavaDocs should be @moduleCode instead of @address 😃

JavaDocs should be @ModuleCode instead of @Address

Since assignment starts with a vowel, it should be "an assignment" instead of "a assignment" 😃 The same typo can be found throughout the project. You can consider using the "find in path" feature in IntelliJ to help you find them (Edit -> Find -> Find in Path)

This test case should be removed 😃

May want to consider adding a link back to the main point which is that ProductiveNUS is supposed to help NUS Computing students resolve the problem so that it is clear what the aim is 😃

I also think it may be better to use more passive language? So instead of 'You often...' it may be better to use 'You may often...'. What do you think?

Looks good! A suggestion could be to bold/box certain words to make the aim more obvious.

The test cases look good! Minor nitpick, the comments next to the valid test cases do not match what is being tested. Also, if the lesson names do not accept numerals in the name, you may want to consider changing the validation regex to only accept alphabets 😃

Nice test case 😃

okie

Naming the deadline field time may be more appropriate for the Lesson class as it doesn't really make sense for a Lesson to have a deadline.

address name should change to module code after merging the PR that changed the address field to module code

Sounds good!

Amended 😃

Since we are probably going to be adding an edit feature in the future we can just leave it in first or add it to v1.2 since the implementation is all done for us already 😄

LGTM.

Will description 'Tags your assignment with a reminder which adds it to 'Your reminders' section' be clearer?

Noted! I have edited the phrasing. Is the edited version clearer?

I have changed some of these user stories to make it more specific. eg. 'work'

Perhaps refer to DG to see which is better?

Updated accordingly 😄

Looks good! Just a small suggestion, maybe we can standardise the use of capital letters under 'I can' and 'so that I can'. we can either capitalise the first word or not capitalise the first word for both scenarios 😃

Sounds good! Which do you suggest is better? I'm fine with either way 😃

Looks good! Just a small suggestion, maybe we can standardise the use of capital letters under 'I can' and 'so that I can'. we can either capitalise the first word or not capitalise the first word for both scenarios 😃

Sounds good! Which do you suggest is better? I'm fine with either way 😃

I think for now we can not capitalise for both scenarios !

Amended 😃

Yup, we should standardize comments. I think we can just follow the style you suggested. Everyone okay? @raymondge @itssodium @chiamyunqing

is it be better to use comment.trim().isEmpty() instead of comparing it to null?

i think you can use the TODO function so its easier to check what you have to do next time

eg.

//TODO: your todo item here

i'm not very sure, does the java doc require the parameter and the return value? eg.

'''

/**

Returns true if a given string is a valid age.
@param test....
@return boolean.....

**/

'''

same for the java docs here!

okay can!

is it better if we do addpatient instead of addPatient? just asking out of curiousity, no need to change if you think its fine

i think this should be addPatient instead of add?

do you think we should add in details like the temp must be 1dp or that the age must be in the range from 0-120?

hmm, why do you need this variable? Essentially, the numofRoomsInString is equal to Integer.toString(numOfRooms). so maybe you can just use that instead of declaring another variable?

so for this, you can just use Integer.toString(numOfRooms)

maybe you want to change the name to SearchPatientDescriptor? can rightclick, refactor -> rename

not sure if this will fail the checkstyle because of multiple empty lines

i think you can change the Person's to Patient's

i think that this method might be a bit long, so maybe you want to extract out some lines of code into a new method? Its just a suggestion, it's fine without it also

I think the one that was removed is correct? Might need to check

is there a reason behind initializing the numerOfRooms to -1?

perhaps it might be good to catch the exception for negative integers inputted by the user?

Sorry, I don't really understand the need for a PriorityQueue in this class, can you explain the rationale for ti?

can i know whats the purpose of this constructor? because its empty but yet it takes in an integer parameter

i think i saw the method below this comment in the RoomBook class, so there might not be a need for this method here?

same as the previous comment, this method might be a duplicate?

since you are creating a new room every time the user adds a room, i think the previous data in the room might all be wiped?

this might be a duplicate method too?

it's only null for now right?

i think this might override the data of the previous rooms too?

i think you might want to change your naming for the priority queue and not use rooms? i got quite confused trying to read it

since you are only counting the number of occupied rooms directly, will there be a problem with this? eg.

i have 3 rooms

room 1
room 2
room 3

So lets say room 1 and room 3 are occupied. so numberOfRoomsOccupied = 2 correct? But next time if you load the RoomBook, it will give me room 1 and room 2 occupied since the numberOfRoomsOccupied is 2?

is the name of the file lol?

this indentation might be abit off?

let's work with the naming together for the test cases next time!

is there a purpose for this method?

i think you can delete this method if it is not in use

hmm, i dont really think there is a need to test if the priority queues are equal? or if you want to test, you can just do

'''

int[] array1 = roombook1.toArray();

int[] array2 = roombook2.toArray();

Arrays.equal(array1, array2);

'''

i think better naming of the paths would be good? it's a little bit hard to understand/remember what the constructor of RoomOccupancyStorage is supposed to take in

by accident? maybe a slip of the finger?

hmm, but i think you can just chain the methods together? like .getRoomBook().getRooms() etc

hmm, i thought that this field not supposed to be here anymore?

Hopefully we won't get merge conflict for this when we merge our UI hahaha

thanks for helping me to change what i have missed!

same here, thanks for catching this

should we make it such that there cannot be patient with the same name?

Is there a typo here? don't think we have UndoCommand and RedoCommand right? hahha

if this part is not needed, then will it be better to just delete it?

i think you can delete this line and subsequently, the convertPriorityQueue method

can delete the method below. i dont think it's in use anymore. i only created it to bypass the need for an observablelist

i'm not sure why it cannot be yyyyMd, is there a difference?

i think he used it because it allows easier tracking of the tasks due date using DateTime instead of a string

Very good use of ObservableList, this will help immensely in the integration into the UI!

i think this should be null dateTime instead of email?

i think this prefix is already used for periodOfStay in PatientCliSyntax.java, will it be affected?

thanks for cleaning up my unused method from before! 👍

i think its fine. It makes me wonder if I should convert my editroom prefixes to p/ instead of pn/ for patient name. hahahah

makes sense, let me change it later

oh ya, i forgot. ill change it later

okay, let me change it now and update the pr

yup, i think i missed out on that, thanks!

i thought its already editpatient?

okay can can

whoops, let me rectify that

the - means that its deleted

all the red lines are deleted lines!

okay, will change it, thanks!

okay can, I will change it

i think instead of arraylist, it might be better to use ObservableList directly. ObservableList is what is passed into ListView (UI component) and allows the UI to be updated whenever there is a change in ObservableList.

okayy, ill change that real quick

yup, i will change the indentation. good catch

alright man, i have reverted all the wildcards imports! thanks for pointing it out

UPPER_CASE shoudnt be in markdown

There is no line breaking here.

LGTM

quick start should start with ##

The contents should be hyperlink

I will add the hyperlinks

the list should have the ``

I think there should not be indentation here

Should it be "the list of all tasks"?

should it be "list all tasks"?

Same as above

are we going to skip displaying or just display an empty list? If we are just displaying an empty list, is it still considered an extension?

list all tasks

the list of all tasks

same as above. i'll ignore it for the following parts

Is 'exit' inside the use cases? should we add it?

This is still not changed

The class here is still not changed to Task

Why extra indent here?

Why extra indent?

same here

nice!

Should we use trimmedTitle instead of trimmedName?

Do you wanna change "address book" to "PlaNus" now or do it later?

Does the name "fullTitle" make sense?

Why extra indent?

just to check, the corresponding UI class variable is also changed right?

What's the rationale of changing it to Amy?

agree. and better put date as yyyy-mm-dd

the attribute in the userguide says date: tho

Should have clearer documentation here

Clearer documentation pls.

Why is this private variable in between to public variables?

I think a better documentation is : construct an empty Description when user didn't provide the description field. Caveat: Only called when the user didn't key in this field.

Same. private variable in between public variables.

Same. I think the documentation can be better.

I would recommend making this documentation clearer as well. Add another line to specify that this is only used to construct an empty Phone when the field is not in the task.

Nice that you changed the UML as well.

oops, I think this should have been "description". My bad I forgot to change this. Can you change it?

Should we really allow type to be any string? Or just one word letters connected by '-'

Should I just delete it or mark it as coming soon?

got it

nice catch

Just mark it as done when you finish your part

What are left to be done for the use cases? Maybe can add inside description?

'''suggestion

Tertiary student

'''

'''suggestion

'''

Don't commit .iml files.

'''suggestion

Tools:

'''

Newline at EOF.

parseEmail should be renamed to parseDate with the corresponding parameter renamed. Same for all other instances.

parseTag should be renamed to parseCategory with the corresponding parameter renamed. Same for all other instances.

parsePhone should be renamed to parseAmount with the corresponding parameter renamed. Same for all other instances.

'''suggestion

 * Parses an {@code String amount} into a {@code Amount}.

'''

'''suggestion

 * @throws ParseException if the given {@code amount} is invalid.

'''

'''suggestion

 * @throws ParseException if the given {@code date} is invalid.

'''

'''suggestion

 * Parses a {@code String category} into a {@code Category}.

'''

'''suggestion

 * @throws ParseException if the given {@code category} is invalid.

'''

'''suggestion

 * Parses {@code Collection<string cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> categories} into a {@code Set<category cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf">}.

'''

parseTags should be renamed to parseCategories with the corresponding parameter renamed. Same for all other instances.

'''suggestion

The UI consists of a 'MainWindow' that is made up of parts e.g.'CommandBox', 'ResultDisplay', 'TransactionListPanel', 'StatusBarFooter' etc. All these, including the 'MainWindow', inherit from the abstract 'UiPart' class.

'''

'''suggestion

:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a 'Category' list in the 'AddressBook', which 'Transaction' references. This allows 'AddressBook' to only require one 'Category' object per unique 'Category', instead of each 'Transaction' needing their own 'Category' object.

'''

'''suggestion

ecp -> ec ++: index, editPersonDescriptor

'''

Let's update the diagrams at a later stage.

'''suggestion

Simply add the following to 'seedu.address.ui.PersonCard'.

'''

Let's revert this change since we will most likely be deleting tutorials eventually.

'''suggestion

   Person editedPerson = createEditedPerson(personToEdit, editPersonDescriptor);

'''

Could you import EditCommand.EditTransactionDescriptor instead?

'''suggestion

Adds an income to the finance tracker.

'''

The command result display is not big enough to display everything, nor can it be scrolled. Instead, the words are just cut off.

Should something else be used instead of menu? Having to click the Menu, then the MenuItem for tabs is very clunky. An alternative is JavaFX TabPane.

I don't think the help menu should be grouped with the other options as the other options are tab headers while the help menu is a menu.

This extra line break can be removed.

'''suggestion

 * Opens the analytics window.

'''

Missing full stop.

panelLabel does not seem to correctly reflect the chosen tab.

Note how Income is selected, yet the label displays Expense.

If the JavaFX TabPane were used, I don't think you need to write such hacky code.

'''suggestion

 * Creates an {@code ExpensePanel} with the given {@code ObservableList}.

'''

Should this class be dealing with Expense objects instead of Transaction objects?

'''suggestion

 * Creates an {@code IncomePanel} with the given {@code ObservableList}.

'''

Should this class be dealing with Income objects instead of Transaction objects?

Any reason why these imports aren't grouped with the others?

Move this import up with the other imports, and leave a line after the last import.

This might be due to the bug found by @zhaojj2209 whereby switching tabs works only for the first time since the application was started.

Unable to reliably replicate this. I'll close this comment for now and keep and eye for this bug occurring in the future.

@siddarth2824 will be addressing this in a separate PR.

See https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/75#discussion_r501141034.

pitest can be added at a later time when we get around to achieving full coverage.

My bad, removed test.

I thought that the GITHUB_TOKEN secret was being blocked due to this PR being from a fork. Seems to also happen with branches on this repo. 😕

Apparently, GITHUB_TOKEN cannot be used; must be a GitHub user's personal access token.

Setting the baseurl to be the repo name is necessary for GitHub Pages to function.

CI job is able to run now. Tested on a branch of this repo as PRs from forks are unable to access secrets.

See https://github.com/AY2021S1-CS2103T-W16-3/tp/runs/1160121842.

@yongping827 The corresponding comment in AddIncomeCommandParser does not have a full stop, should I still add it?

This was left as such to mirror the corresponding change in #56. Can I confirm this is not intended?

Edit: Never mind, just saw https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/63#discussion_r499263026.

Full stops to be added separately. This is honestly very low priority.

I was wondering why IntelliJ was throwing warnings for the pitest task in build.gradle. See https://github.com/szpak/gradle-pitest-plugin#eliminate-warning-in-idea. For documentation purposes only; I agree that this change feels less readable.

Requested for permission to use the external library at nus-cs2103-AY2021S1/forum#253.

LGTM!

While the current deployment process works with personal access tokens, @wltan brought up the point that we should have it work with the repository token GITHUB_TOKEN instead. This is a more ideal solution, especially if Prof Damith were to adopt the use of jekyll-spaceship.

Relative links are currently not working. Trying to find a fix.

PR has been picked up by the grading script.

Closed with #50.

Screenshots

Desktop:

Mobile:

Could you rebase to address merge conflicts before we start reviewing?

Can consider renaming function to execute_invalidPersonName... instead of Index since we are editing by name now.

Just a side note, can consider "editPatient" as command word in case we want to have an "editTask" command in future. Up to you! 😃

Good use of Optional here!

Typo @code instead of @cod

I like how you included this test!

Your implementation of editpatient supports editing multiple fields in 1 command. Can consider adding an example of this. E.g. editpatient Alex Yeoh c/Add comment d/20200303-20200315

In the example, should be editpatient not edit haha ><

Perhaps you want to consider changing the message to "Search for patients who fulfill the given criteria in Covigent." since the output may be a list of patients.

Personally, I think including an example for search via temperature range may be better since this may be more difficult for users to understand how to use.

Actually you can remove the isPersonFound attribute totally. if (personName.equals(nameToSearch) can just return new CommandResult(String.format(MESSAGE_SEARCH_PERSON_SUCCESS, personFound)) directly. If the execution of code proceeds beyond this for loop, can just throw new CommandException outside. Just a suggestion to keep your code shorter 😃

Good test coverage!

Good to include an attribute string for message usage (similar to the other commands)

Will be good to include a MESSAGE_SUCCESS attribute or something similar for the string " rooms are added in a hotel" (can refer to the other command classes to see what I mean).

E.g. in addPatientCommand your have the attribute String MESSAGE_SUCCESS = "New person added: %1$s";

So what you return is return new CommandResult(String.format(MESSAGE_SUCCESS, numPersonToAdd)) instead of the hardcoded string.

Just to clarify, this exception is thrown if the user did not call the command addnumberofrooms right?

This attribute was what I was referring to for MESSAGE_USAGE earlier. Perhaps you may need to shift this attribute to AddNumberOfRoomsCommand class instead to keep it consistent with the formatting of other command classes.

Ok actually I am kind of confused of the flow and purpose of the addNumberOfRooms command. I thought for first time user we will get them to initialise the number of rooms and that will be fixed through out the usage of the app. So addNumberOfRooms in this case should be for initialisation? It doesn't make sense if halfway throughout the usage of the app I suddenly call addNumberOfRooms command again unless I built more rooms for my facility. 😕

Actually why do you need to add code for room under AddPatientCommand?

Just curious, why did you choose to use PriorityQueue instead of something simpler like ArrayList? 😛

Good test coverage for Room!

Remember to delete this!

This will be handled by allocate person command no worries.

Nice!

If we have to convert to priority queue, do you guys think if it's better to use array list directly instead of priority queue for room list?

Right, that's true!

Should be after search patient command but it's okay for now. We will do a massive UG clean up in future as a group 😃

Will be starting with an empty "room list" or something instead of AddressBook. Just to clean up traces of address book from the code haha.

I agree with this too. There may be errors if we forget to update this variable when needed.

Neat class that adheres to format of the existing codebase!

I was just wondering why you need to have a date time created attribute for task 😛

Neat I like this!

Good test coverage.

As in I meant the attribute "DateTimeCreated" haha, like why do you need to know when the task was created 😛 . The tracking of tasks due date is by attribute "DateTimeDue".

Sounds good!

Thanks for spotting this :X

Good! We will need to add test codes for patient addition for editRoom command too.

Very neat!

Sounds good. I've changed the names to AddPatient instead of AddPerson for better clarity. However, if we are going to implement Staff, maybe can extend from Human instead of Person because there will be too many changes required to replace Person to Patient.

There's a possibility that comment may be a null object (since it's an optional field) and .trim() method exists for String class so it wouldn't work if comment is a null object 😛

That's a very good suggestion, will use this function in future! 👍

I followed their existing format. 😛 Since checkstyle doesn't give error, I assume it's fine?

Yes!

Yep I will change to add patient instead!

Thanks for pointing out!

I think the temp should write but the age probably no need haha.

Yes, good suggestion. We definitely should adhere to this in the next UG update!

Yep, should take note of the standardisation in UG.

I agree with Ming De I think we should stick to making sure patient does not have the same name. If we delete by index, in the case of 1000 entries, the user may have to scroll too much to find the patient (using searchpatient command doesn't show the index also 😕).

If we just ensure patient cannot have the same name, then all we need to change is the isSamePatient(...) function (to guard against duplicate patient being entered). If we need to check for the age and phone number identifiers, then we may need massive changes for deletepatient and editpatient command 😕.

Well, we can justify that the odds of patients having the same name is really very slim haha (https://www.quora.com/What-is-the-probability-of-two-people-having-the-same-name-and-also-living-in-the-same-city)

I realised I should be making the pull request from my fork instead of editing directly in this repo for UG.

Incorporated with editRoom command.

Agreed. The user might not know the exact start and end dates of his semester, and we also do not need to take into account the user entering invalid start and end dates if we provide them for the user instead.

AY20/21 Sem missing a '1'

*Duration is measured in hours and must not exceed 24 hours

Same rephrasing as above comment

*has

Can omit the second line if we are providing them with the start and end dates?

Will listpresettasks be more intuitive since it will be a list of preset tasks?

Remove a Module and all its Module Tasks from the Module Schedule

*load all its Module Tasks

If its "CS2103T", maybe we can change it to MODULECODE

Do we have a method to list all the task templates or will the GUI take care of that?

Use either remove or delete

Agreed

*listmymodules

List all the modules that the user has selected.

tasks*

Maybe can change to List all tasks instead of Listing a Task Schedule? As schedule itself refers to a list of tasks

Think you might have added an extra '.' at the end!

Should it be 'parameters' instead of 'parameter'?

Should SERVICE_CODE be added here?

maybe can replace 'additional' with another word, or just write 'displays a success message'?

*updates

*requests

*deletes

*match

*shows a, *match

*an

*displays

*an

*At least one service exists in the service list

Does it guarantee an empty service list as well?

maybe can change description to details?

*service

*GrAB3 shows the list of expenses sorted in ascending order

would it be better to remove tutorial slots part cause we don't really have a tutorial?

'''suggestion

'''

'''suggestion

'''

'''suggestion

        + PREFIX_TAG + "CS2103 Tutorial "

        + PREFIX_TAG + "Experienced";

'''

'''suggestion

Edit Student | 'edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [t/TAG]…'
e.g.,'edit 2 n/James Lee e/jameslee@example.com'

'''

I think someone forgot to change this previously...

'''suggestion

'edit-student 1 t/@johndoe e/johndoe@example.com' Edits the telegram handle and email address of the 1st student to be '@johndoe' and 'johndoe@example.com' respectively.

'''

Hmm... I think putting it at the top would be more convenient for users to just take a quick look... But the word 'summary' makes it feel like we concluding something so its weird for it to be at the top... Why not change the heading to like 'Command List' or something equivalent?

I think keeping the previous would be better also... The previous formatting was based on the original user guide we got for the address book... so i think it is fine that the table and commands not consistent.

I think clear is used to clear all students though... delete is meant to delete a specific student...

'''suggestion

Listing all students : 'list'

'''

'''suggestion

Clearing all students : 'clear-student'

'''

'''suggestion

Editing a student : 'edit-student'

'''

'''suggestion

Clearing all classes : 'clear-class'

'''

Perhaps it might be good to follow the same format as 'DeleteStudentCommandTest' to be consistent?

'''suggestion

Contains integration tests (interaction with the Model, UndoCommand and RedoCommand) and unit tests for
{@code EditStudentCommand}.

'''

I like how you specify that clear removes all students!

'''suggestion

public void addStudent(Student student) {

    students.add(student);

}

'''

Would this be a better name?

'''suggestion

public void resetData_withDuplicateModuleClasses_throwsDuplicateModuleClassException() {

    // Two moduleClasses with the same identity fields

    ModuleClass editedCS2103T = new ModuleClassBuilder(CS2103T_TUTORIAL).withStudentIds().build();

    List<student cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> defaultStudents = TypicalStudent.getTypicalStudents();

    List<moduleclass cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> newModuleClasses = Arrays.asList(CS2103T_TUTORIAL, editedCS2103T);

    TutorsPetStub newData = new TutorsPetStub(defaultStudents, newModuleClasses);



    assertThrows(DuplicateModuleClassException.class, () -> tutorsPet.resetData(newData));

}

'''

Would this be a better name?

'''suggestion

//// Student related tests

'''

'''suggestion

/**

Wraps all data at the application level.
Duplicates are not allowed (by .isSameStudent and .isSameModuleClass comparison).

Perhaps a line break here will make it look less cramp?

'''suggestion

    Index outOfBoundIndex = INDEX_SECOND_ITEM;

    

    // ensures that outOfBoundIndex is still in bounds of Tutor's Pet list

    assertTrue(outOfBoundIndex.getZeroBased() < model.getTutorsPet().getModuleClassList().size());

'''

should this be

'''suggestion

// identity fields

'''

same for the data fields comment

Perhaps this comments and the few below should start with lower caps?

'''suggestion

    // one keyword

'''

would it be better to leave a line here?

'''suggestion

     // manually link first class to first student

    ModuleClass moduleClass = model.getFilteredModuleClassList().get(0);

    Student student = model.getFilteredStudentList().get(0);

    Set<uuid cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> studentUuids = new HashSet<>(moduleClass.getStudentUuids());

    studentUuids.add(student.getUuid());

    ModuleClass modifiedModuleClass = new ModuleClass(moduleClass.getName(), studentUuids);

'''

perhaps this comment should start with lowercase?

''' suggestion

private TypicalModuleClass() {} // prevents instantiation

'''

perhaps this should start with lowercase?

'''suggestion

// manually added

'''

Perhpas this is missing a full-stop?

'''suggestion

// Manually added - Student's details found in {@code CommandTestUtil}.

'''

perhaps this should start with a lowercase?

'''suggestion

public static final String KEYWORD_MATCHING_MEIER = "Meier"; // a keyword that matches MEIER

'''

Perhaps this would be a better naming?

''' suggestion

public void execute_indexSpecifiedListIsNotFiltered_showsStudentsInClass() {

'''suggestion

public void execute_invalidIndexSpecifiedClassListIsNotFiltered_throwsCommandException() {

'''

Would it be good to specify which list?

'''suggestion

/**

 * Removes all {@code studentUuids} from each and every {@code ModuleClass} in the class list.

 */

'''

Perhaps student manager would be a better name?

'''suggestion

/**

 * Removes all {@code Student}s from the student manager.

 * Also removes all {@code UUID}s from each {@code ModuleClass}.

 */

'''

I am not sure about this... But should the full-stop be after the example?

'''suggestion

/**

 * Ensures that Tutor's Pet will not be able to boot up given an incomplete {@code UUID}

 * (e.g "0c527a3f-8a6f-4c16-b57d-").

 */

'''

Perhaps it will be a good idea to keep the formatting consistent with the subsequent tests?

'''suggestion

/**

 * Ensures that Tutor's Pet will not be able to boot up if two or more {@code Student}s are found with the same {@code UUID}.

 */

"something is wrong" feels a little generic.. Perhaphs it is good to specify?

'''suggestion

        // Check that the set of student UUIDs within a class is a subset of that of

        // all student UUIDs in uniqueStudentUuids. Otherwise, Tutor's Pet would not

        // boot up due to data corruption.

'''

I guess the refactor cant detect that... THANKS!

HAHA cause dexter added that in his i think

That test was missing so i just added it and made it consistent with what was in EditStudentCommandTest

Actually does the user need to list all modules first before adding a new one ah?

Maybe an empty list shouldn't affect the addition of a new module? If not a user can never add his first mod since the list will be empty then LOL

'''suggestion

Duplicates are not allowed (by .isSameModule comparison)

'''

Should we update the default pathname to gradpad.json or something along those lines?

I think we can update the javadocs for these changed methods 😁

'''suggestion

 * Adds a new {@code Module} to the {@code GradPad} that we are building.

'''

This test fails cos 2 Modules shouldn't be equal if they have different module codes. Perhaps we can remove the module code change

'''suggestion

    Module editedAlice = new ModuleBuilder(ALICE).withTags(VALID_TAG_CORE)

'''

I think we need to update TypicalModules.ALICE cos the tests can't build since ALICE is an invalid module. It'll probably be good to rename it too LOL cos alice is still a person's name

Maybe we can rename the dummy path since we're no longer building addressbook 😁 Same goes for the change on line 46 below

'''suggestion

    userPrefs.setGradPadFilePath(Paths.get("gradpad/file/path"));

'''

Same as prev comment

Maybe we can remove the regex split? It doesn't do anything since module codes never have spaces in them. Maybe we can just create an array with the module code in it as a single string:

'''suggestion

    String[] keywords = { CS2103T.getModuleCode().moduleCode };

'''

This is exactly the same as the 'CS2103T' in the prev line HAHAHA so it'll always return true LOL

In this test, we are seeing if modules with the same module code and MCs, but different tags, will be considered the "same" by GradPad, so maybe we can just change the tag:

'''suggestion

    Module editedModule = new ModuleBuilder(CS2103T).withTags(VALID_TAG_NON_CORE)

'''

Nit: I think we need to update the javadocs for this method

Let's change these example tags HAHA altho I wish modules could give me friends and money...

'''suggestion

public static final String MESSAGE_DUPLICATE_MODULE = "This module already exists in the grad pad";

'''

Perhaps we can rename the variable 'editModuleDescriptor' here and also the references in the few lines below it.

'''suggestion

    EditModuleDescriptor editModuleDescriptor = new EditModuleDescriptor();

'''

'''suggestion

public static final String MESSAGE_DUPLICATE_MODULE = "This module already exists in the grad pad.";

'''

'''suggestion

/**

 * Stores the details to edit the module with. Each non-empty field value will replace the

 * corresponding field value of the module.

 */

'''

'''suggestion

/**

 * Creates and returns a {@code Module} with the details of {@code moduleToEdit}

 * edited with {@code editModuleDescriptor}.

 */

'''

I think we need to update the javadocs here 😁

'''suggestion

Deletes a Module identified using its displayed index from the grad pad.

'''

Perhaps we can use camelCase for the property names? JSON properties are basically hashmap keys; so just like how we wouldn't use multiple words (with spaces) in a key or variable name (altho JS/JSON allows), maybe we can use moduleCode or module_code instead?

'''suggestion

 * Constructs a {@code JsonSerializablegradPad} with the given modules.

'''

Not a suggestion/request for change, but I was just wondering why the original code does this redundant check here when it could just call gradPad's 'setModules' fxn, which already uses 'UniqueModuleList' to ensure all modules are unique.

I just put this comment here first in case we want to improve code quality next time.

'''suggestion

List gradPadModules = modules.stream().map(JsonAdaptedModule::toModelType).collect(Collectors.toList());

try {

gradpad.setModules(gradPadModules);

} catch (DuplicateModuleException ex) {

throw new IllegalValueException(MESSAGE_DUPLICATE_MODULE);

}

'''

I think we need to rename the file also 😁

I think this test assertion is the same as the one a few lines above 😁

Since it's supposed to include other valid values, perhaps we can do:

'''suggestion

    userInput = targetIndex.getOneBased() + CODE_DESC_CS2103T +  INVALID_CREDITS_DESC + CREDITS_DESC_CS3216;

    descriptor = new EditModuleDescriptorBuilder().withModuleCode(VALID_CODE_CS2103T).withModularCredits(VALID_CREDITS_CS3216).build();

'''

Nit: the test is perfectly fine but maybe we can replace the dummy keywords with module names

The 'lastModule' is already CS3216 right HAHA so we don't need to "edit" it with the same code and credits again

'''suggestion

    Module editedModule = moduleInList

            .withTags(VALID_TAG_CORE).build();

'''

😁 I think the re-naming of the variable was missed out

'''suggestion

A utility class to help with building EditModuleDescriptor objects.

'''

'''suggestion

 * Parses the {@code tags} into a {@code Set<tag cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf">} and set it to the {@code EditModuleDescriptor}

'''

nit: typo

This module is valid HAHA

It's why the test for invalid module in JsonSerializableGradPadTest isn't passing

Updated these 2 badges so that when you click on them, they take you to our repo's CI and codecov pages respectively:

Let me know if this regex is fine cos I'm not too sure what kind of module codes we support

I left the contents unchanged for now as I only needed the tags as defaults

I added module field templates here and left the rest of the templates alone. We can remove at the end if nobody else needs them

I only added CS2103T and CS3216 as new modules in this class and left everything else alone first. Likewise, if nobody else needs them, we can remove them at the end

Ui looks great but I think the website says it has to be the ard the same size as the original. Right now it's too big:

Feel free to resize, update the PR, and merge in your own time! 💯

I think this issue is too big and general? Maybe each person can create an issue specific to their work e.g. my issue should be "Add feature list and command summary to user guide" since I'm doing first page of our google docs

Shouldn't the text name for this be matriculationNumber?

Maybe INVALID_MATRIC_NO could be changed to INVALID_MATRIC_NUM instead?

Shouldn't there be a method call withMatriculationNumber(...) as well?

Perhaps MATRIC_NO_* could be changed to MATRIC_NUM_*?

Should there be an awkward line break right after MATRIC_NO_BOB? Same issue with the other test cases.

Shouldn't there be a method call withMatriculationNumber(...)?

Shouldn't the message be ATAS has deleted all students! or something like that?

Perhaps these could be renamed to ACCEPT_COMMAND_FULL, ACCEPT_COMMAND_SHORT, REJECT_COMMAND_FULL and REJECT_COMMAND_SHORT?

Perhaps comments could be added to explain what you're testing for each statement (+ expected result)?

I noticed a similar issue previously. Maybe more comments explaining each test case could be added?

Do you think it would make more sense to include the use of the abstracted wrapper class Index here?

Would this make more sense to put in an if-else block (with comments to describe the else block)?

Should this unncessary extra line break be removed?

Maybe these could be renamed to PREFIX_SESSION_NAME and PREFIX_SESSION_DATE?

Shouldn't the form be dd/MM/yyyy?

Maybe some comments could be added here to more clearly explain the thought process?

Unnecessary additional line break?

Maybe these two if blocks could be merged into one?

Would it make more sense if all instances of SESSIONNAME got changed to SESSION_NAME? (same for SESSIONDATE and SESSION_DATE?

Unnecssary whitespaces?

Unnecessary whitespaces?

Unnecessary extra line break?

Unnecessary line break?

Unnecessary whitespaces?

Shouldn't this be renamed to Editing a student to fit the rest of the item naming?

Thanks for pointing this out, as well as in other places!

Should this be project book?

Should we replace getTempFilePath("ab") to getTempFilePath("pb")?

Should the variable be named pb instead of ab?

Should this be named pb instead of ab?

Should the indentation here and in the method below be 4 spaces from the parent comment?

Is there a reason for adding this? These lines were removed in the previous PR as we removed those fields

Just to confirm, the only time this test will fail is when the description is empty right

Should there be an empty line before the @param tag?

Agreed, maybe we can create a new PR for this after merging all the important features for milestone 1.1.

Should there be an empty line before the @params tag?

Is the requireAllNotNull() method here supposed to check the description as well?

I believe the description parameter is not optional as of now, right?

I think the code here should be rearranged so that it is a little clearer. The modelName variable should be delared after the if (!Name.isValidName(name)) block

Minor typo here

Is there a variation of this test that you have written?

Not sure if this Javadoc adheres to the coding standard

Javadoc here should be StopCommand instead of StartCommand

Should these two checks be extracted out into another method to keep the equals() method here clean?

Should the javadoc here be more descriptive?

Should have an empty line before the @param tag

Should the equals() method below check whether both timers are equal?

By below I mean in the Project.java class, can't really highlight it from here.

Javadoc comment needs to be updated to include timer

Why not just use the otherProject variable here?

There should be an extra line before @params tag and a description for what is returned after the @return tag

Should include an empty line before the @params tag

Can I just check what the reason for changing this was?

I think the commands here can be highlighted once again. For example

/home brings the user to home dashboard

Should we replace these images with @khoodehui 's mockups? At least the ones that are ready

If I'm not mistaken, all existing tags will be removed and only the tag normal will be left. Should we mention this?

Should we separate format and examples into two columns?

Can replace this with @khoodehui 's mockup as well

Should these sentences end with a fullstop

As discussed, description will be implemented as an optional parameter instead. A new PR will be created for this issue.

as of v1.2 there is no feature that requires the generation of reports

interacting with GUI with a mouse* ?

Again, no reports yet

include date and time

This is not in v1.2

Don't edit the tutorial

Parameter name not changed

Good

uses '@' symbol

Comment: 32nd not 32rd

Comment needs to be updated

Looks like you forgot to change these comments as well

Comment should be day greater than 31 instead

Is it supposed to be date or Date, previously it was Phone not phone

KIV the prefix because this includes date and time

Perhaps it should be named modelDateTime

Missed this out

I personally feel that date and time should be separate, e.g. 01-01-2020 1200, we can discuss this in the team meeting tonight

Should probably be on separate lines

Should be named something more meaningful like status or taskStatus

Shall discuss whether these fields should be optional in the team meeting later tonight

Should be DATE_TIME

does this prefix make sense or do we need to revise it since its date + time now, maybe it should be due: for example

What is the purpose of this design wise? Is this to act as a null value without throwing NPE?

The rationale behind using java String#trim on Phone was to remove leading and trailing whitespaces. When considering the user's dateTime input do we need to consider white spaces inside the string as well? For e.g. "01-01-2020 1200" vs "01-01-2020 1200" if we are not going to trim it then perhaps we need to consider adding an exception for this and add the corresponding unit test.

Remove this

rename this

rename the date

added extension

These are in addremark.md not actual code, not sure if it needs to be changed

same reply as above

ok undid changes in these documents, please review again

not in this PR

changed

done

changes reverted

Does not LGTM. Please include markdown for important commands or things to note of. Thanks.

Please include your portfolio under team/GabriellaTeh.md

Resolved merge conflicts and created a new pull request from a different branch

TaskTemplate instead of Task Template/Preset Task Template

Should Preset Task just be Task only?

For now maybe we should use remove the spacing between Task Template, Task Schedule, Module Schedule etc.

Probably should try to use module code instead of index

modules*

has to be an integer from 1-7*

has to be a valid positive integer. The Total number of weeks are calculated using the start and end date of the semester*

weeks*

has been completed*

Displays all tasks in the week that is specified by the user

has to be a valid positive integer. The total number of weeks are calculated using the start and end date of the semester.

Total weeks in the semester

Creates a template of tasks for the user to reuse weekly to quickly add into his/her schedule

List all task templates that were created

Creates and adds a preset task in the selected task template

has to be an integer from 1-7, 1 being Monday and 7 being Sunday

Clear all preset tasks in the selected task template

Rmb to change the capitalisation for UG

Maybe listtemplatetasks would be a beteter name

List all preset tasks in the task template

Maybe listallmodules will be a better name

Ternary ? should hour instead of hours

Should name the class name as Day.java

Refactor Days to Day

Some have full stops and some don't

Can consider using the Amount class so Price will store an Amount instead of a big decimal

Yup its quite referenced from the original AB3 tests

Better to merge this after everyone updates their profile in the aboutus page

Amend commit to update DG use cases with suggestions from @khoongwk

Not sure if add remark changes were accidental for this branch but would be useful to have it to serve as the description for tasks 😸

LGTM

Added some tests

I like your specifying: STUDENT_INDEX and CLASS_INDEX

Perhaps it is clearer to define 'index' as follows?

'''suggestion

*'STUDENT_INDEX' refers to the index number shown in the displayed student list.

*'CLASS_INDEX' refers to the index number shown in the displayed class list.

'''

Minor grammar issue, should it be 'is' and not 'are'?

'''suggestion

5a. At least one of the given indexes is invalid.

'''

Same as issue above.

'''suggestion

5a. At least one of the given indexes is invalid.

'''

Should we include test cases for UUID? Such as public void toModelType_nullUuid_throwsIllegalValueException().

Apologies, mistake on my part for not typing correctly. Should be

'''suggestion

public void toModelType_nullUuid_throwsIllegalValueException() {

'''

Otherwise, looks good to merge.

Should the tense follow the 'DeleteStudentCommand' class instead?

'''suggestion

public static final String MESSAGE_DELETE_MODULE_CLASS_SUCCESS = "Deleted Class: %1$s";

'''

Nice abstraction.

Should the filtered list be specified?

'''suggestion

 * Updates {@code model}'s {@code filteredStudents} list to show only the student at the given {@code targetIndex} in the

'''

Same as above.

'''suggestion

 * Updates {@code model}'s {@code filteredModuleClasses} list to show only the ModuleClass at the given {@code targetIndex} in the

'''

Same as above.

'''suggestion

 * Updates {@code model}'s {@code filteredModuleClasses} list to show no module classes.

'''

Perhaps naming studentIds as studentUuids would make the code clearer?

Should there be at least one class entry here? We can follow invalidClassTutorsPet.json, which has a valid student entry.

Should you insert a INVALID_STUDENT_IDS list (and test case) also? Perhaps you can use a string that has less than 4 hyphens

Nice handling of null UUIDs. However, would it be better if a try-catch block is used on UUID.fromString(uuid) instead? Then, any kinds of wrong UUIDs can be handled.

I think you missed out on this:

'''suggestion

public static final String MESSAGE_DUPLICATE_MODULE_CLASS = "Class list contains duplicate class(es).";

'''

I think you missed out on the TODO comment. Perhaps instead of importing these STUDENT_UUID_X in test cases, we can call ALICE.getUuid() from TypicalStudent class instead.

Should this for loop be placed in another method for proper SRP? The for loop above that iterates through jsonAdaptedStudent can be similarly placed in another method. Then, this toModelType() method will call these two for loop methods.

To add on, according to Java's UUID API, UUID.fromString() throws IllegalArgumentException. Perhaps you can use this alongside with your null guard clause.

I notice this try-catch block appearing in other parts of the PR. I think the proper way would be to write our own interface for UUID. But, for now, I think it is not needed.

Should you indent this line?

'''suggestion

<fx:root minHeight="600" minWidth="740" onCloseRequest="#handleExit" title="Tutor's Pet" type="javafx.stage.Stage" xmlns="http://javafx.com/javafx/11.0.1" xmlns:fx="http://javafx.com/fxml/1" cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf">

''' </fx:root>

I noticed that these 3 lines of code are repeated in above test cases. Perhaps can consider abstracting these out into a private method?

Should this be:

'''suggestion

    ModuleClass specifiedClass = showStudentsInModuleClassAtIndex(expectedModel, INDEX_FIRST_ITEM);

'''

Should this be in the same 'format' as above?

'''suggestion

    assertCommandSuccess(new ClearModuleClassCommand(),

            model, ClearModuleClassCommand.MESSAGE_SUCCESS, expectedModel);

'''

Would it be better to test against the moduleClasses directly? Since we are adding (and removing) them along with their studentUuids.

'''suggestion

    assertFalse(modelManager.hasModuleClass(CS2103T_TUTORIAL));

    assertFalse(modelManager.hasModuleClass(CS2100_LAB));

'''

Similar to above.

'''suggestion

    assertFalse(tutorsPet.hasModuleClass(CS2103T_TUTORIAL));

    assertFalse(tutorsPet.hasModuleClass(CS2100_LAB));

'''

Yup

@junlong4321 yup, that is right.

@dextertanyj agreed, will remove a student not in any classes.

Perhaps can add a description saying that this is the constructor?

Should be project book instead of address book.

Same here too as above comment.

Perhaps there should be a whitespace after the slashes?

Yup think it will better to describe that it will construct a new project, just like the javadocs in other classes.

Will it be better to give an example of how the ISO8601 time format looks like in the error message? A user might not know what this format is.

Should have a new line before the param.

Think the persons here should be timers instead.

Should have a new line after the description. Same for the 2 methods above.

Newline after description.

Extra line here should be removed.

Extra asterisk here should be removed.

Newline after description.

Newline before method.

Should we remove all the navigation commands first? Since they are not yet implemented.

Description has been changed to an optional field.

Should both name and description be optional fields here?

I think we can indicate [coming soon] for this.

I'm not sure if this section should be done by @boundtotheearth, since he implemented this and according to the tP instructions, it is recommended that features in the user guide should be written by the person who implemented it.

Similarly, should we remove this first or indicate it as [coming soon]?

Same as above, for Create and Update, some of the fields are/are now optional.

Not sure if it would be better to rename this as 'Editing a project'? It might be more clear that the name of the feature is the same as the command.

I think it should be. Because it doesn't make sense for the user to have to enter something for the name when they are not intending to change it. I think we might have made a mistake when writing this section of the user guide.

So the edit command will be like the addressbook's, where all fields except index are optional, but at least one of the optional fields must be provided.

Same case for **Note:** here as above.

Seems like markdown isn't converting **Note:** over here to bold. I think it's because it's embedded inside HTML. Try using Note: instead.

I think the asterisks here are causing Markdown to not format the table correctly.

This was following the discussion yesterday, there is no view command for profile.

Maybe it will be more consistent to change type to category?

Also, I think this was left out in the issues, but the switch command can be added too

Do you think it is good to be overly specific about the type of error? If so then there are many more extensions to include such as inputting an index that is not a number for example.

I am unsure about this myself but what if there are no items in the list? what kind of interactions can the user and system have? I know your preconditions addresses that but do we have to consider the case where you call edit and there are no items in the list?

Really minor a UI not an UI

Should be an exception instead?

Should be an exception instead since you are not testing an assumption?

Should be an exception instead, since exceptional case

The other JD comments are in the other PR, you can ignore them for now if you want unless you it is finalized

Sure we can have a common package for the fields within model package but for unique fields with own regex, keep them in the feature's package.

Minor nit, should be Sets in the Javadoc

Same thing here. Minor nit, Should be "Sets"

Same thing here -> Sets

Change -> Changes

Same minor nit Set -> Sets

Set->Sets

There are 2 more that require changing below:

Initialized
set

Javadoc comments below as well for set.

Perhaps its more appropriate a throw an exception here since assertions are mainly to check for precondition and post condition of function execution and testing assumptions. This usage fits neither and is more of an exceptional case?

Same issue here ? You are not testing assumption here, exception better?

I think you may be missing a line break here?

The profile command is updated with [t/TITLE] and [d/DESCRIPTORS]...

I think you have have missed out deleting this UC05

You can ignore this first. The content page can be changed after all the headers are in.

nvm, its good to merge, I have updated the contents page to link to my headers.

Okay, will update!

yes. These did not have preconditions, I'll remove them.

True, I should remove this, I think the only precondition then is that the system is running which is not very meaningful in this case.

Okay will make the change!

sounds good!

Yes, there will be multiple descriptors which can be added similarly to tags.

I think this is the work of IntelliJ auto injecting imports. I will move it.

I was going for a primitive implementation for now, but since the types are fixed, I think enum is good solution too.

I stopped changing this because I was unsure if we need 2 levels of inequality for profile items.

I have not created exceptions yet so this is a placeholder

I didn't change this yet since this was the original file but I suppose like it can be changed now too.

Sounds good! I was thinking of doing so after the other parsers are done since for example the EditParser for the InternshipCommand may want to abstract 3 items (comindex, index ,prefixes)? So it depends on implementation of the parsers first then after which we deal with abstraction for common vars.

Yep, some of initial JD do not have full stops too.

There were changes in the branch, need to resolve some conflicts! @seanjyjy

I noticed that many of the javadocs used "person" and "address book", should we change it now? or leave it for later?

Hmm. The dilemma now is that this is just a proof of concept and we may be abstracting common logic down the line and scrapping all these, so overwriting Javadocs now may redundant. The danger is that if the code is kept and the comments are missed in the future. What is the team's opinion on this? @ZoroarkDarkrai @keanecjy @seanjyjy @shawn-nyk

Yup I think that there isn't a need to concern about javadocs / comments as of now as they can be easily fixed at any point in time. @orzymandias I stopped editing the List portions as I noticed that there were too much code duplication with your pr. Do we plan to either extend an Item class or use generics for our list?

I agree. I think there is unnecessary duplication for collections, generics is a good idea for collections but one issue is with throwing custom exceptions for different types of items within the generic list. Should we just have DuplicateItemException then something like throw new DuplicateItemException(T.getDuplicateExceptionMsg())?

ecessary duplication for collections, generics is a good idea for collections but one issue is with throwing custom exceptions for different types of items within the generic list. Should we just have DuplicateItemException then something like throw new DuplicateItemException(T.getDuplicateExceptionMsg())?

I don't think this works because we are not able to access methods in java generics. I figured since we all are classifying our classes as Item, we can have an Item interface to contain all the methods similar methods like isSameItem and likewise do throw new DuplicateItemException(item.getItemName())?

Sounds good.

Overall looks great, just some nits to fix.

Just a side question as to would it be confusing as AddCommandParserWrapper is essentially Similiar to DeleteCommandParser, however, they have different naming syntax.

Is this implementation temporary in order to allow ab3 to function properly?

For AddCommandParserWrapper each item has its own set of parsing rules which may require their own individual parsers so the AddCommandParserWrapper is only responsible for funneling the appropriate item prefix to its add parser. The thing about delete command parser is that there is lesser parsing involved except for extracting out the index to be deleted. With the exception of internship which has an additional index required, all the other commands just need the index extracted to be passed to their delete commands. So I am not sure there is a need a wrapper in that case.

As for consistency I think once AddCommandParser can be safely removed, we can rename AddCommandParserWrapper to AddCommandParser.

Just a small grammar error. I think it should be students' and not student's?

Maybe it will be nice to change tutees to students? Since we are using students at all other places.

Perhaps it will be better to remove contact since users can edit tags as well. And tags may not be contact information.

Perhaps it will be great to include the format here as well?

'''suggestion

List Students in Class | 'list students /by [n/CLASS_NAME] [m/MODULE_CODE]'
e.g., 'list students /by n/Tutorial T10 m/CS2013T'

'''

I think you forgot to change the example?

'''suggestion

List Students in a Class | 'list-students c/INDEX'
e.g., 'list-students c/3'

'''

Nice! 👍

I like this. But i think we need to update the examples in user guide since users don't have to type @ now

Should there be a space before comma?

I don't think there should be address?

'''suggestion

    // Keywords match telegram and email, but does not match name

    predicate = new NameContainsKeywordsPredicate(Arrays.asList("12345", "alice@email.com"));

'''

'''suggestion

 * Returns an {@code TutorsPet} with all the typical students.

'''

Good catch!

I think this should change to 'AddModuleClassCommand'?

'''suggestion

 * Parses the given {@code String} of arguments in the context of the AddModuleClassCommand

 * and returns an AddModuleClassCommand object for execution.

'''

Is it possible to change 'Node' to 'Label'?

'''suggestion

 * Creates a {@code Label} with the given {@code Tag} details.

 */

public Label createTag(Tag tag) {

'''

Or alternatively change the 'Label' in JavaDoc to 'Node'?

I think there is a missing space.

'''suggestion

-fx-background-color: derive(#7392b7, 10%);

'''

Is it An UI or a UI ?

Not sure if we should use An UI.

Is there an extra semicolon?

Great job for finding so many missing full stops in comments! 👍

There is an extra space.

'''suggestion

<!-- Checks that every class declaration is followed by an empty line. -->

'''

I just realized that we forgot to write javadoc for getModuleClassList().

Perhaps this should change to 'different objects' ?

'''suggestion

    // different objects -> returns false

'''

Perhaps can add in a test for multiple student indexes/class indexes?

Perhaps this should start with capital letter?

'''suggestion

    // Calls #setStyleToDefault() whenever there is a change to the text of the command box.

'''

Perhaps it will be better to rename key to student?

agree with this

Yep works on mine too

Typo on module

Change to "A contact can have multiple tags."

Can the usage of dots be consistent? Also, add articles (e.g. an assignment) and change 'the' to 'a'

Change to 'a user', 'the user', and 'opens'

No need to use 'the'

Erase 'the'

Should there be a space here?

Not a department

Shouldn't this be different department?

Not a department

Change to Information Systems

Not a department

Change to Information Systems

Lowercase D

Should this be duplicate modules?

Perhaps change to personsCs1101s to adhere to the coding standard?

Change naming to adhere to coding standard

I agree, might be mistaken for Name in Person

I think it is a good idea, it is more descriptive (and has the same format with ModuleName)

Sounds like a good idea

I think "module" here should be "modules" instead.

"Lists all modules provided by the university"

Unless 'n/' command is taken, I think we should use "n/" instead of "un/", it seems more intuitive for the user to add his/her own name as "name" rather than "username"

Should we allow the user the flexibility of determining start and end date? Isn't it better to only allow the user to specify the academic year, and we will provide the start and end date for the user. I think this would make it more convenient for the user.

Similar concern to my above comment, whether we should use "n" instead, as well as whether we should allow the user to have control over the start and end date semester.

'DAY' has* instead of have. Also, I think it'll be good to capitalize first letter of the days Monday and Sunday:)

Similarly, "WEEK" has*.

Additionally, "Total number of weekS".

If we do decide that user shouldn't be able to select start and end dates, then the total number of weeks will be pre-determined already.

Same grammatical error as above comment

There's an additional 'e' here in "edituseretask"

task ID example given here is not really consistent with the sample command (line 248) which uses "id/usrta001". Additionally, the example command here uses "dy/3", I think it should be "da/3".

I feel that the command could be better named, for example using "edittemplatename" instead. Although its a slightly longer command, however it gives more clarity than "edittemplate" as to what the user is editing. "edittemplate" gives off the impression that I can edit preset user tasks in the task template?

Why is this named "listtasktemplate" instead of "listtemplate" for consistency with the above commands "edittemplate" and "createtemplate"?

Grammatical error:

"total tasks for that day exceeds"

Similar grammatical error for "exceed"

I don't you need "pti/1" in a cleartemplate command.

Grammar: I think it should be "List all the task templates that were created" instead

Is MODULEINDEX here a list index like "3"/"5", or would it be a module code like "CS2103T"?

I think deletetemplate here should have a "tti/TASKTEMPLATEINDEX"

In the e.g given, cleartemplate shouldn't have "pti/1"

I think we are going to omit MyModules from the architecture, we will be using ModuleSchedule instead, so this use case should be View ModuleSchedule instead

Should we follow the three part format for naming of test methods?

Likewise for the naming of the test method

Similarly for the naming of test method

Same here for the naming of test method

Thanks for the comments @khoongwk @yanlynnnnn , I have made the changes as requested!

Thanks for the comments @khoongwk @yanlynnnnn, I have made the changes as requested!

@seanjyjy is going to redo this part(?) so should I ignore this?

Could be confusing saying job name because the format actually uses the position of internship in the company?

I don't think these are the right precondition and guarantees?

just a nitpick but I noticed that other use cases use list user profile items instead user profile item?

shouldn't precondition be the state of the system and not the user?

Another nitpick, maybe it's better to use InternHunter rather than the app? As the next points use InternHunter rather than the app?

I think you missed this comment?

I think you missed this comment an others below too?

should be instanceof UserProfile?

is it the user profile?

type is category right? because it can only be either education, skill, or achievement should it be an enum instead?

I assume this is a planned extension for the profile items to have tags?

should be two profile items? and several comments below

should be profileItem? and for other comments below too

wrong exceptions in this file or are they placeholders?

Is it switching to the applications tab?

I noticed you changed of a company to in a company for others

for consistency maybe use tab because we usually describe them as tabs and not pages(?) for this and others below

this is a really small nitpick but i feel the flow of the second sentence can be improved? just feel a bit weird having the if any in the middle.

maybe something like any applications with the deleted internship, will also be deleted?

is this safe when string length is <= 1? or is it guaranteed that the length > 1?

validity?

any reason why an assert instead of an exception?

oh yeah, thanks for noticing 😅

I noticed that many of the javadocs used "person" and "address book", should we change it now? or leave it for later?

LGTM, good work! Some merge conflicts to resolve first.

Fixed!

Maybe can add the person to be deleted is not found?

Same for accommodation and activity use cases also

So its not the command format but the error is missing person/accommodation/activity

Should we handle duplicate person/accommodation/activity when adding?

Need add use cases of edit function? Or too long already

Think the command is called 'show' instead?

I think can change address to location class? Since our user guide its location class. Can just import from activity.

Should be setAccommodation instead

Exception class shld be accommodation, same for the next one

unable to find specified accommodation

duplicate accommodation.

Should passport and mobile number be a data field since its a tag? Not compulsory for users to input.

If phone and passport is not identity fields, it shldnt be here alr

we shld restrict phone number to 8 digits for SG

Have to change regex already to maybe this d{8}?

can just initialise to private final Phone phone. Same for all classes. Just import the package at the start can alr

Same problem no need full package name

editedPerson change to editedFriend

Should change person to activity

Same

Wishlist

activities

Ya but i dont know what badges we should add, there's quite a few different one

Ok added

Changed

Maybe change the sections (deliverables, contacts, meetings) to their respective epics, following our meeting docs? E.g. this line of code can be "[EPIC] As a Product Manager, I can track my product’s development so that I can work better towards production deadlines. (Deliverables)"

Noticed you left out type of Product Managers in here and elsewhere (e.g. "Product Manager who needs to be aware of changes in description of deliverables"). I believe we can leave these out for now. Just a note.

For consistency, can we change to just "mark deliverables as completed"? (I'll update the changes on the docs)

Can we change to small caps 'm' for 'Minimise'?

In here and elsewhere, should we follow the user stories as closely as the gdoc since it's more or less cross-checked among ourselves? i.e. for this line of code, can it be 'contact the right person if needed'? Alternatively, 'locating the right person easily' would work, since this user story is about editing the POC.

Should we take out "(completed deliverables / total deliverables)" since it may lead to confusion? It may be misunderstood as completed deliverables or total deliverables instead of over. Alternatively to explicitly state "completed deliverables out of total deliverables".

For consistency, can we have "keep them up-to-date" for the 'so that' portion?

Can we have back the 'remember and retrieve important information' under 'so that' portion?

Can we capitalise the 'i' in 'keep any data that i want'?

Can we have plural 'contacts' instead of 'contact' under 'so that' portion?

Did you miss the epic "As an inexperienced or forgetful Product Manager, I can refer to a user guide as I’m using the app so that I am able to use it as intended"? The user stories in this epic are not reflected.

Here and elsewhere, noticed the numbering isn't correct, but I believe markdown solves this automatically. Have to check again? Just a note.

In here and elsewhere, for consistency, can we ensure all the lines end with periods (.)?

Can we ensure the use case IDs are in consecutive order, i.e. this should be UC11 and delete contact should be UC12?

Can we change to singular 'Deliverable'? (side note: we may need to redefine this keyword. Personally it sounds slightly vague though I know this definition was taken from online).

Should we leave this keyphrase out since I don't think we use it anywhere?

Can periods be included for all the epics too?

Have seen that the rest have periods now. How about this line too?

I believe you added the 'so that' portion wrongly here. It should be for the "view my contacts and their relevant details" user story under EPIC B. Could you help to change that?

Could we change this to "view a helpful popup"? Just a small grammar error.

I think your suggestion would work for now.

Can we fix the typo here? Maybe in the next big commit for UG. Just to note.

Will create another PR for this commit.

No need to review/merge.

Is it necessary to perform test after check? I believe check already includes test.

https://stackoverflow.com/questions/50104666/gradle-difference-between-test-and-check

Duplicate https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/13#discussion_r492195636

Do glossary terms need to be italicized? May need to standardize.

Can I confirm that this line will be left unchanged? Otherwise LGTM.

Ok, we will review this again towards the end of v1.2.

Can we verify that this workflow runs smoothly on our repo?

Perhaps you can push an equivalent change directly to a non-master branch first, and see what happens to the gh-pages branch.

Ok, as seen from https://github.com/AY2021S1-CS2103T-W16-3/tp/commit/65e48f7a1f38c68e643cb29f8d29e0951f06bc4c the CI is able to build and deploy GitHub Pages properly.

Suggest extracting these changes to their own commit/issue/PR as they are technically not related to the issue at hand.

See above (https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/23#discussion_r495016936)

Minor typo fixes can be left as part of this PR.

Similar to https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/7#pullrequestreview-492595656, Cygwin messes up on CRLF line endings in the scripts. Not a major problem; the hooks will work as long as the scripts are changed to LF line endings.

After discussion, changes can be left in this PR, but should be separated into different commits so that they will show up in the squashed commit upon merge.

These don't look like intentional changes 😕

https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/39#discussion_r495585791 same here

Minor typo:

'''suggestion

'''

Indentation still appears to be slightly off here compared to the previous state

'''suggestion

        xmlns:fx="http://javafx.com/fxml">

'''

'transaction' is no longer the parameter name

'''suggestion

 * Returns an add expense command string for adding the {@code expense}.

'''

This should be changed as well, my bad!

'''suggestion

 * Returns an add income command string for adding the {@code income}.

'''

Perhaps the variable name should be ft instead of ab?

Also I don't see any method signature for withTransaction(String, String). Is this a problem inherited from the original AB3?

Same as above, consider changing ab to ft.

Note that placeholders johndoe.md and johndoe.png are being removed as they are no longer needed.

It was found that the shell scripts do not produce any output unless problems are detected.

To make the pre-push hook and CI job more useful, the changes in #23 will also modify the scripts to print their status as each check is being run.

Note that while we intend to rename test methods to match the new model, we will leave the test data alone for now and revisit it in a follow-up issue.

https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/39#pullrequestreview-497089729

Update the package names too to ay2021s1-cs2103-w16-3.finesse as discussed.

Edit: My bad, hyphens are illegal characters. How about ay2021s1_cs2103_w16_3.finesse as recommended here?

Recommend doing this in a separate PR. Refactoring the package would generate a large diff and make it difficult to review the model renaming.

Now that #39 has been merged, all that is left is to delete the Address class, which is incidentally one of the CS2103T tP tutorial tasks.

Looks like theres a formatting issue here

I think we should turn the 4 into a constant, i.e. private static final CALORIC_MULTIPLIER = 4. Same for the rest of the macronutrient classes

Similar to the toString function, I think we can factor this out to the superclass. If we do that then we can also change all its protected access modifiers to the ideologically superior private.

Looks like you're using the assertion incorrectly, it should be

assert amount >= 0 : "amount cannot be negative"; instead.

Currently it will print the error message regardless of whether the assertion passed or failed.

Also a side note: we should use the java logger instead of System.out.println apparently.

Maybe you could add a TODO comment on what kinds of methods to add to this class/how it should be used.

e.g. // TODO: Food FoodMethodHandler.combineFood(Food firstItem, Food secondItem) or something

IIRC we need to write javadocs for each class according to the module specifications.

IMO we should keep this as the string "Carbohydrate" instead. Makes the code more explicit.

Same for the other macronutrients

I think we should @override the object.equals method instead. Having 2 methods claiming to do the same thing will invite bugs.

This method only makes sense if we have unique objects in the list, maybe you could change the target to the Index of the object in the list, or require all objects in the fridge to be unique.

Same as the setFood method

I think we should rename this to macronutrientType or something so we don't confuse this type with a java type.

Assertion here could be more descriptive (e.g. "Macronutrient type cannot be blank"), since we are changing name to type.

We should be checking for referential equality here i think? i.e. assertTrue(expectedFridge == fridge), not sure if object equality is intended.

Same as below comment

typo in caloriMultiplier.

Also I think you MacronutrientStub or something would be a better class name. The current one sounds like this is an object that creates other macronutrients.

Should remove this or put a TODO comment if its blank

I think this should be withFood or something

Also is using person here intended?

I think a comment would be good here to say it takes the name from the class name

Maybe we should change int index to Index index, i.e. the class from AB3.

I think we should keep this as just assertThrows instead. We should stick to the static asserts for tests

same for all the other test files that were changed

Hmm looks like I may have accidentally removed this during the safe delete or something, will update and restore it.

Yes that seems to be better. Good catch.

I'll add a couple more tests for this, along with some unit/integration tests with the Commands.

Nope, if you try to declare multiple of the same parameters there will be an assertion error somewhere.

Technically you can work around this, by declaring a new class that contains the two parameters, e.g.

the command:

'takeTwoIntegers 1 2'

may have a parameter

'private Parameter param = this.addParameter(..., IntPair::parse)'

and the IntPair class is as follows:

'''java

class IntPair {

public int a;

public int b;

public parse(String str) {

IntPair result = new IntPair();

result.a = ...

}

'''

Don't think any of our commands will involve these kinds of parameters, but if they do we may have to either redesign the command or the parser. (We'll solve that problem when it happens)

Yes, for the first one the 1 will be considered as input to the -n parameter, and the unnamed parameter will have no input (so there will be an error).

I'll add this and the comment below into the PR's docs.

No point imo since I'm not reusing the string outside this function.

Also would add more noise which we're gonna change anyway (when we change people to food).

good job

Added a skeleton to Duong's PR. Should be able to add on from there while avoiding merge conflicts.

(related note: can someone approve that PR? don't think I can do it because I also contributed a commit.)

We should use the same format as the one from AB3 (copied over below).

Use case: Delete food

MSS

User requests to list persons
AddressBook shows a list of persons
User requests to delete a specific person in the list
AddressBook deletes the person

Use case ends.

Extensions

2a. The list is empty.

Use case ends.
3a. The given index is invalid.
- 3a1. AddressBook shows an error message.
  
  Use case resumes at step 2.

The CI test says that you are missing the shadow plugins

Seems like a github actions issue. This happens from time to time.

Closing and reopening the PR should restart the CI process (hopefully fixing this).

LGTM

'''suggestion

Edits an existing tag in StonksBook to the specified tag name. All entries previously associated with this tag will be updated to associated with the updated tag.

'''

I think we can remove 'the' here

'''suggestion

All contacts that have been previously associated with this tag will be updated automatically to be associated with the updated tag.

'''

Should we mention friends here? I think it may be better if you just mention that it updates the name of the first tag (as per tag list)

Same comment for here (about whether to mention friends)

Maybe we should consider switching to an ordered list if we're going to make reference to other points

Think you're missing a Use case ends. here and in some other portions below as well

Can this be indented to be the same level as 2a? Likewise for the remaining use cases

'''suggestion

StonksBook adds the provided tag.

'''

'''suggestion

'''

I think here we're assuming that contacts are sorted before sales right? Should we add a comment stating this assumption?

Can we write this section into an if-else block with the above? Then we can also remove some duplicate code

Hmm, is associations a bit hard to understand here? Would it be better to be more verbose here and say something like Note that all items that have been previously associated with this tag will be updated automatically to be associated with the updated tag. as per the user guide?

P.S. May also need to update the user guide: it currently says contacts when it's supposed to be generic right?

Same feedback here as in DeleteCommand

Is this comment still relevant? If I'm not wrong it refers to the tags stored in the persons/sales right?

Javadocs here is inaccurate

Would it be better to initialise a new HashSet with the original tags, remove the target, then add the editedTag in order to prevent arrowhead-style code? Same can be done for the removeContactTag

This should be equivalent tag instead of person right?

Should be tags here instead of persons

Is this javadoc accurate?

p.s. i think these 2 lines are common across the conditionals. maybe we can extract it out of the conditional? same for EditCommand

Thanks for pointing that out!

Oh, my bad. I didn't know the new line would affect the formatting. Thought it was just code styling. Will remove it!

@Asthenosphere ps can help resolve the merge conflicts?

LGTM

Thanks!

Think we're all done with this. Nice work all!

Shouldn't example usage (below) be updated to include the IC field as well?

Shouldn't a javadoc comment be included similar to the other models?

Shouldn't there be a multiple ICs test?

Shouldn't there be a missing IC prefix test?

Shouldn't there be an invalid IC test?

Shouldn't parse_oneFieldSpecified_success and parse_multipleRepeatedFields_acceptsLast also have tests for IC?

Shouldn't there be tests for null and invalid IC?

Shouldn't it be BloodType instead of weight?

If you refer to the javadoc for the other methods, shouldn't it be @code String BloodType and @code bloodType?

Shouldn't it be bloodtype instead of weight?

Shouldn't there be a description of the parameter?

Should it be Constructor instead of constructor?

Javadoc comment does not follow the coding standards

Shouldn't it be there be a space before Blood type: ?

Shouldn't it be BloodType.MESSAGE_CONSTRAINTS instead of Weight.MESSAGE_CONSTRAINTS?

Shouldn't it be blood type instead of weight?

Shouldn't all the missing field prefix test also include VALID_BLOOD_TYPE_BOB so that the tests would be consistent with each other?

Shouldn't it be blood type instead of weight?

Shouldn't method header comments start with a verb?

The class header comment is not consistent with the class header comment like Phone or Email

Perhaps it would be good if we insert our website here.

Perhaps we could keep keep this so we can change it individually

Perhaps we could keep keep this so we can change it in future

Perhaps we should keep the product name consistent, to Insurance4Insurance, I4I

Perhaps we can add a "Coming soon." here

Perhaps this could be "Adds a client to I4I."

Perhaps this could be Format: add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [o/NOTE] [t/TAG]…

Perhaps this could be

Examples:

add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01
add n/Betsy Crowe t/friend e/betsycrowe@example.com a/Newgate Prison p/1234567 t/criminal o/This client is new.

Perhaps this could be Lists the entire list of clients in I4I.

For now, for v1.2, I think we would try to minimise the amount of fields to delete, so we would add in NOTE and keep the rest. However, this may change in v1.3/1.4, so we can update the UG then.

We can add back the "Tip" for tag if you are okay with the above change.

Perhaps we can format INDEX to INDEX.

Perhaps we can edit to Example: list followed by delete 2 deletes the 2nd person in I4I.

Perhaps we can add a Coming soon here

If you are okay with above edits to add, perhaps we can change to this:

Add | add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [o/NOTE] [t/TAG]…
e.g., add n/Betsy Crowe e/betsycrowe@example.com a/Newgate Prison p/1234567 o/This client is new. t/friend t/criminal

Perhaps we can add in help as well, since we are implementing in v1.2

Help | help

Perhaps we can add this back, since we are implementing help in v1.2

But we would need to update the image to https://ay2021s1-cs2103-t16-2.github.io/tp/UserGuide.html

Perhaps we should change this to

Wraps all data at the client-list level

Reopening this issue as PR was accidentally merged

Note that this PR was merged by accident, reopening issue and creating another (similar) PR

Resolves #6

Ensure that source should be <= 50 characters.

Update URL and image in UG

address
email
phone

I'm not sure if <ins> is the correct tag to use here? (And the closing tag should be </ins> right) From what I gathered online <ins> is to underline some text in html to indicate it is an insertion, but there's not <del> tag here, so I think it might be more appropriate to use either the  tag for underlining or []() syntax if its supposed to be a link

I think we should retain the step of copying our jar file over to the folder the user wants to use as the home folder, as we'll need to do saving in a data folder as well

There's inconsistency between this and the description of the help command below. Also, I think the help contents will be opened in a window and not a page?

Refer to comment above

Maybe we should change PHONE to PHONE_NUMBER, following the original format, for clarity

'''suggestion

Shows commonly used commands for TBM.

'''

'''suggestion

Role: In charge of deliverables and deadlines

'''

Following the format for client delete INDEX, maybe add a short one line statement to explain what this command does?

Same as prev comment, and there's also an extra newline here that I think would be better to remove

The indexing is off here

Indexing off here too

'''suggestion

1a. The list of clients is empty.

'''

Might want to change this to match the original "Finds clients whose names contain any of the given keywords.", and change n/NAME to KEYWORD [MORE_KEYWORDS] as the format section below mentions keywords

'''suggestion

The search is case-insensitive. e.g 'hans' will match 'Hans'
The order of the keywords does not matter. e.g. 'Hans Bo' will match 'Bo Hans'
Only the name and country are searched.
Only full words will be matched e.g. 'Han' will not match 'Hans'
Persons matching at least one keyword will be returned (i.e. OR search). e.g. 'Hans Bo Russia' will return 'Hans Gruber', 'Bo Yang', 'Alice Katya'

'''

'''suggestion

Listing all clients: 'list'

Shows a list of all clients in the address book.

'''

'''suggestion

Finds clients whose names contain any of the given keywords, or whose country of residence contains any of the given keywords.

'''

I think we should just stick to either the abbreviation TBM or the full name in the headers, not both

either that or perhaps change both back to the simple "User Guide" and "Developer Guide". I don't really see a need to have TBM in the title, as the whole website is already about TBM, plus we have introductions and our home page.

Just to add on, I don't think the <ins\ cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> tag should be used here, as markup defines it as inserting something? e.g. here. <u\ cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> seems more appropriate if the intention is to underline the text. </ins>

LGTM

I think you should keep "Developer".

I checked again, and I think you missed out the find sales history feature under sales tracking.

I agree.

I think that this should be specified as a sub feature under list, so as to distinguish between all ingredients and a single ingredient.

Perhaps this archive employees contact details section should be grouped with the other employee contact details features?

I think this page will be continually updated, so we should include what we have done to the project so far - which would be the documentation section.

For the ingredient levels, it would be good and clearer to state the unit of measurement. You could add this to the description or edit the examples to show this is the case.

We are missing Feature 4.3 Find the sales history data based on date documentation.

Remove the bullet points in this section to standardise the description field for the features. Instead of starting with a noun, start with a verb (once again to standardise across the UG). Eg. Set the level ...

Since it's just one argument, requireNonNull(targetIndex) will do.

I think we should keep both. They will both be Phone objects, but with different prefixes.

Requires change to fit ArchiveList

Perhaps you can use requireAllNonNull(...) instead.

Should this be using .equals method instead to do the check?

You are missing empty lines in between the methods.

IngredientList should not be under AddressBook, as AddressBook should only be in charge of contact details.

Mismatched javadoc?

As mentioned earlier, functions and features relating to ingredients tracking should be abstracted out to its own classes (instead of being in AddressBook).

I assume this has yet to be implemented?

Incorrect test case? Should these be all throwing assertion errors instead? They should not be called as it is a default model stub that have all of the methods failing.

LGTM

small issue maybe it should be example instead of examples?

same issue here

there seem to be some inconsistency here. do you mean JOB_TITLES instead?

do you mean job_title

I think what Shawn said makes sense. It might be better to stick to terms that are already established eg InternshipStatus. If I am not wrong does the status class exist only for Internship? If that is the case, maybe you can consider shifting date to the Internship object instead and as such, there won't be any ambiguity in the naming.

small typo

might want to maintain consistency with other files where you leave a line at line 9 for this class.

there shouldn't be a return

I realized that some javadocs there's full stop while some there aren't.

If most to all parser requires these static final int variables, we could shift it to avoid duplicates. However, I am not sure if it is apt to shift it to an interface. Can consider having a Util class for it.

the parameter should have a space

I am wondering if since the Internship has been categorized into InternshipCliSyntax, perhaps this could be also categorized into ItemCliSyntax, or were u planning to convert this class into that in the future?

hmm i am not sure which "style" we want to stick to but shawn has another way of writing this InternHunter detects an error in the input format . We might want to stick to one way in order for our DG to look cohesive.

should use

Would it be weird if it is "viewing" the profile page? To be cohesive to our DG, You must be on the **profile** page ... sounds more cohesive to our precondition

an exception should be only thrown when it is like not within the programmer's control? like missing files or user input. Since it is a controlled environment, using assertion is more apt. It's from oracle java assert.

Yup, It might be more consistent to change the type to category.

Thanks, @keanecjy will add the missing information. Maybe it might be more apt for us to put it as "what our app manages" under introduction

Yup we could keep it simple currently and once we merge them in the future, we could include those extensions.

perhaps once we merge the similar use cases together, we can include more extensions to it!

hmmm, I am not very sure if it should be an exception instead. I was following the assert from oracle java.

'''

The absence of a default case typically indicates that a programmer believes that one of the cases

will always be executed. The assumption that a particular variable will have one of a small number

of values is an invariant that should be checked with an assertion.

'''

Have fixed the java docs issues, thanks.

I will resolve this conversation since we have concluded it.

True I am not sure about which is a more appropriate wording.

Thanks for the spot, will update it.

Thanks for the clarification Shawn, what I meant as this naming is, Company & Application to have the same Information Width. I will do the relevant changes to make it clearer.

LGTM

#87

LGTM

If we are planning to create other classes in replacement of person and address book, I don't think we need to change the Javadoc yet?

#48

#99

Hmm. The dilemma now is that this is just a proof of concept and we may be abstracting common logic down the line and scrapping all these, so overwriting Javadocs now may redundant. The danger is that if the code is kept and the comments are missed in the future. What is the team's opinion on this? @ZoroarkDarkrai @keanecjy @seanjyjy @shawn-nyk

I agree that overwriting Javadocs now may be redundant, especially because our code can change over time up until the final version. At the same time, I also agree that we may miss them in the future, and doing a one-time run-through of all our code at the end may be very tedious and error-prone. As such, how about we do something like: every time we create new bits of code that require Javadocs, or we modify code that already has Javadocs attached to them, we place a standardized comment, such as TODO: Javadocs above the code we need to write/edit Javadocs for? That way we get the syntax highlighting that IntelliJ provides for the TODO keyword, and we can also search for this standardised comment throughout the code base to hone in on where we'll eventually need to write/edit Javadocs when the time comes. Any thoughts on this?

I think this is a great idea what do the rest think?

#104

#100

LGTM good job.

Hi, Fidella I think since you approved these changes I will just merge it in? Need this code currently

"Question " but no biggie

"QUESTION " instead of "Name"

medmoriser**

medmoriser*

Medmoriser* methods

medmoriser*

medmoriser

medmoriserStorage*

medmoriser*

medmoriser list? question set list?

different question *

questions*

invalid question*

different question

wrong place

Can you change this to docs/UserGuide.md

Should we remove this *{More to be added}* line?

Can I ask what is gradeDist? Is it grade distribution?

Can I check why we are checking if other is instanceof Name? We should only check if other is also a Location right

Another instance here. I think should be other instanceof Location right?

Should we use Address Class for Task as well? I am unclear if there is a difference between Location and Address class class haha

Just curious, why did you remove the (String) typecasting?

Need to fill in return value here

Can I check, what is the difference between setModule and setModules? They are for different use cases?

Should ass throws ModuleNotFoundException, DuplicateModuleException to the method declaration right? Same for several other methods.

Just thinking. Shoudl we change this TrackItManager? Or TrackIt? haha. If it's too troublesome to change then nevermind.

Ok then we just leave it first. If need be we will let the others add in these methods when they implement further

Maybe we should add throws NullPointerException in the method declaration? Or remove that line in comments.

Can delete the @return here as well, or add the return value

Is this method supposed to be empty?

Can I check why this is removed? Are we leaving it to later to implement?

Why is @Override removed? The getTaskList method is from ReadOnlyTrackIter so we should keep the @Override right?

Is this the final PR for concrete classes? If yes we should re-enable checkStyle

Ok I tried to change to this but err java gives me an error: Illegal escape character in String literal

Just finished refactoring. I think we can merge this first then I can create another PR where I rename the files to AddContactCommand? and etc

Also rmb to fix issue brought up by Weihong. criminal lawyer is not alphanumeric.

https://discordapp.com/channels/@me/763052081266950177/763128915186155520

I think the link for UserGuide should be this one? (https://ay2021s1-cs2103t-f13-4.github.io/tp/UserGuide.html)

The current one brings me to https://github.com/AY2021S1-CS2103T-F13-4/tp/blob/docs/UserGuide.html#quick-start instead.

Similar to UserGuide, I think the DG link is this one? (https://ay2021s1-cs2103t-f13-4.github.io/tp/DeveloperGuide.html)

Sorry, I think this 'food' is not changed yet.

Should we change address book to food inventory here also? Same for line 158, 162, 166.

Very minor and we are going to delete address anyway, but do you think this should be address instead of simplykitchen?

Should the "Persons" here be "Food Items" instead?

Should "persons" here be "food items" instead?

Very minor, but should we change "addressBook" parameter to "foodInventory" instead?

I think the "bar" in statusbarPlaceHolder should be "Bar" instead? Since it was changed to "Bar" in MainWindow.java.

Very minor, but should this be expectedFoodInventory instead? Line 112 and 117 as well?

Very minor, but should this be Food Inventory instead?

Should SimplyKitchen Inventory be Food Inventory instead? Line 137 as well.

Extremely minor, but should "an" be "a"? Also should "persons" be "foods" instead?

Very minor, but do you think we should switch back to Label for consistency?

Very minor, but should the comment for invalidity be different?

I feel that since priority is no longer optional, should we set the priority directly without the Optional here?

Should we have a priority missing test here as well?

Okay changed

Changed all comments with name to description.

I agree, changed them. Thanks!

Yeap I agree. Changed them.

Might want to take in the user input and array of prefix, and store it as a instance variable.

No parameters needed, use the instance variable values, SLAP.

change to private

change to prefix

change to private, and change the name of the method, very similar to the one below

change to private, change the name.

Pull it out as a separate class.

SLAP, Abstract out the new ContactList creation.

Wrong object used, should be ResultCommand

Why need isSameContact method and the overwritten equals method?

Is it cos in the event of 2 differnet person with the exact same name?

Should it be final? Might be hard to keep updating right?

Will it work? Since this.contacts is final.

Same thing, contacts is final, im not sure if you can just set it.

Follow SLAP, bring out the remove function call.

Might want to pull this out into a new class for common usage. As I foresee we will be using this for some of the other classes as well.

I will fix in the latest update!

Looks good to merge, just file renaming.

should this be mid-v1.2?

okay agree

I got the same warning and also mentioned here: https://github.com/nus-cs2103-AY2021S1/forum/issues/232

(it's an error log output). So this should be fine

Should the parameter name be client instead of Client?

Should the parameter name be clients?

should Clients be clients?

ohh, if the checkstyle version/file in both GitHub and IntelliJ are already configured properly but the outputs are different, I'm not sure which one to follow. Perhaps @benclmnt have a suggestion regarding this code quality?

I think this is what wei jie means. Perhaps you can change these jsons from "Clients" to "clients"

Or should we ignore the GitHub's checkstyle warning for now and merge, and fix it along the way?

Should this be FitEgo?

Should this be Clients or clients? (for consistency)

should the name be something like "hasFunctionToRun"?

Should this be non-public?

should this be session builder? noticed the same cases in this file as well

should the variable name index be changed? since there are 2 "index"

just curious, any reason why this takes in LocalDateTime instead of String (since the other with__ takes in string)?

in terms of consistency with the other with__ methods, should we pass the String? What do you all think?

Is it better if I change it into:

Use case: UC03 - Edit a Client

MSS:

    1. User requests a list of Clients using `clist` (UC02) or `cfind` (UC04) 

    ..the rest

done

should the find feature be implemented later? Also, the current AB3 only supports search by name

Is this like adding a new command? If yes, should this be for v1.2 or mid-v1.2?

The division of 3 sections is in the other PR. Should we bold the nextSession line?

sorry just read this. both bolded/not bolded looks good for now

Some things to take note:

1. Command has been changed from "[c/CLIENT] [s/SESSION]" to "[INDEX] [s/SESSION]" which makes more sense.

2. 1 issue which is that when the input session is higher than the total number of session, there's an exception on the terminal but nothing is being printed on FitEgo. The issue is with RescheduleCommand only having the [INDEX] which takes care of the problem when [INDEX] > total schedules, but in Parser, I'm not able to retrieve the filteredSessionList as it requires Model to retrieve it, so FitEgo can't detect the issue when input session is higher than total sessions.

3. Testing for this Reschedule is not fully up yet because there isn't a ScheduleCommandTestUtil class, not sure if this is required because now it's a bit tricky in a sense that Schedule contains Client and Session while RescheduleDescriptor contains clientIndex and sessionIndex of Index class. If RescheduleDescriptor were to contain Client and Session, it should be easier but in RescheduleCommandParser, similar to issue 2 above, I'm not able to retrieve the filteredSessionList as it requires Model to retrieve it.

try to detect the issue in command.execute() instead of parser?

Small issue, but should this line not begin with a whitespace? (Even though the syntax highlighting does not appear here on GitHub, I believe it still works to markdown the text in this case so shouldn't be an issue!)

Should we markdown these lines with backticks as well, to put them in code format, as per the other examples?

I assume we're using Person's Name and Phone classes for now since they help guarantee certain text properties. We'll probably have to change this in the future (at least the naming, for example wage being a Phone object seems odd)? Perhaps using String for now may keep things even simpler, but I suppose this works for now!

Perhaps we could name this InternshipStatus or something along those lines instead? Do let me know if I'm mistaken, but it seems that we have a Job class that has the variables - jobTitle, companyName and industry. So this status object should be reflective of an Internship status rather than a Job status? Shall we ensure that "Job" and "Internship" are not interchangeable terms throughout our code base? Another issue that might still arise even after changing the name to InternshipStatus is that we will then have a Status and InternshipStatus class, and it may not be obvious what the difference is between the 2 in terms of their names? Would it be possible/better to make this a private enum within the Status class?

I suppose having this field means in the UI, we'll have some text like "As of: date"?

As we'll also need to add Jobs in a company object, this Job object seems to differ implementation-wise from the Job object that we may use for company objects, though they should probably be the same? For example, in a Company object, during its creation via a user command, the user can input multiple industries and jobs that a company has. This creates the Company object, along with its multiple jobs and industries. So in those Job objects in the Company object, will each of them have multiple industries tagged to them instead of just one industry as in this Job object? Also, since a Company stores Job objects, would this create a cyclical dependency if we change the Name companyName part to Company company in the future (I assume we will)? At this juncture, it seems that if Job is going to store Company and Industry, perhaps we may not even need Job objects? Perhaps we could simply use String (or Name) for jobs? This may also help to synchronize with how jobs will have to be represented in a Company object.

Sounds good to me! Shall check with the rest if they're okay too! (Sounds like in the future we could perhaps repurpose the "Person" package to become like a text-format-enforcer package of sorts?)

Ah I see, thanks for the clarification! I think the Status and ApplicationStatus names suggested work, but perhaps sticking to InternshipStatus might still be better so we don't introduce more terms for the same object (for e.g. application and internship both refer to internship applications)? So maybe swapping the current Status and InternshipStatus names will do? May have to consult the rest haha, just some suggestions!

Ah okay! My bad for missing this out, thanks for highlighting!

Should this return companyName instead?

To stick to a standardization, shall we also rename the InternshipApplication class to InternshipApplicationItem?

I believe these attributes for Company and Internship are the outdated ones?

I see we've changed the tab name from plural to singular. I was wondering if it would be odd since the user would be looking at a tab labelled "Company" but in it can be multiple companies? Likewise for "Application" as well, which to me sounds like I'll view a single application if I click on it. Small matter but perhaps we could discuss this further and see what the team thinks too!

Alright, no worries! Will merge this first and we can settle this next time.

Just to confirm, does company application refer to internship application i.e. our application class in this case?

Ah I see! Thanks for the clarification Sean!

True, this class is indeed very similar to the Name class. However, in order to do the following:

pass in the messageConstraints to signify a different error message if need to

perhaps we can modify the Name class to, say, take in an extra argument in its constructor for the messageConstraints variable, and then the passing in of this variable could be done by the Industry class that extends the Name class and simply passes its own messageConstraints through the parent (i.e. Name's) constructor via super(). As such, we'll reduce code duplication but still maintain the existence of the Industry class. I feel that it may be necessary to have such unique classes because variables such as private final Set<Industry> industries = new HashSet<>(); would look rather odd as private final Set<Name> industries = new HashSet<>();. And ultimately, in order to "pass in the messageConstraints to signify a different error message if need to", I believe we'll still need to have some sort of Name as parent class for subclasses such as Industry, Descriptor, Requirement, etc. arrangement, since Industry is not the only class affected by this / has this characteristic.

All that said, modifying Name and abstracting all the common fields to subclass from it at this juncture would be inappropriate in the context of this PR. Would it be okay if we let this portion through first and do the necessary abstraction / refactoring after all 4 items (inclusive of this Company item) are present in our codebase, as discussed in our Tele group?

My bad, thanks for catching this!

Overall looks great. Good job. Just a few nits and it will be good to merge.

Thanks for pointing them out Sean! Have gone ahead to fix those inconsistencies across the whole doc.

Overall looks great! Just wondering if grouping the 2 stars and 3 stars together would be better? Perhaps edit an object should be considered a high priority as well? Otherwise LGTM

Ok! Made the edit commands high priority, which solved the 2/3 star grouping issue as well!

Hmm. The dilemma now is that this is just a proof of concept and we may be abstracting common logic down the line and scrapping all these, so overwriting Javadocs now may redundant. The danger is that if the code is kept and the comments are missed in the future. What is the team's opinion on this? @ZoroarkDarkrai @keanecjy @seanjyjy @shawn-nyk

I agree that overwriting Javadocs now may be redundant, especially because our code can change over time up until the final version. At the same time, I also agree that we may miss them in the future, and doing a one-time run-through of all our code at the end may be very tedious and error-prone. As such, how about we do something like: every time we create new bits of code that require Javadocs, or we modify code that already has Javadocs attached to them, we place a standardized comment, such as TODO: Javadocs above the code we need to write/edit Javadocs for? That way we get the syntax highlighting that IntelliJ provides for the TODO keyword, and we can also search for this standardised comment throughout the code base to hone in on where we'll eventually need to write/edit Javadocs when the time comes. Any thoughts on this?

Is it better to change this sentence to this?

"This project is based on the AddressBook-Level3 project created by the SE-EDU initiative."

As I feel like this flows better for me.

Should this be linked to our repo's actions instead of the se-edu's one?

no i mean the link not the badges. Now you are linking it to se-edu/addressbook-level3

https://github.com/AY2021S1-CS2103-T14-3/tp/actions

this

I think this line can put?

I'm a bit not sure about this. Is it we can edit the travel plan at top directory also?

dk hahaha

@jiaweiteo @jeannetoh99 @timjkong

According to @jiaweiteo , only the name should be considered as identity fields, while passport and phone should be data fields

i think its better to put getTPOList()

same for all the other TPO

Is it better to have ScrollPane here? As we might have lots of TravelPlan and the Pane cant show everything

Same as above. Maybe we put ScrollPane here

JavaDoc errors

Need, but i thought haishan is also doing this so I left out the edit and show features for her, or I should just do them?

Hmmm I don't know.

@jeannetoh99 @underthehai @timjkong

Maybe can add the person to be deleted is not found?

You mean the person is not found in the travel plan or you mean the person is missing in the input command?

I will add the case for target not found, but the error message one cause I wanted to make them generic so don't need to be too specific. The implementer of that feature can do whatever they want to the error message. What do you think?

@underthehai

I updated it. But I don't know if it works, can help me check?

My CI will pass after merging @jeannetoh99 TravelPlan class

Don't merge first after commiting changes.

I need to think about all the ReadOnlyXXX classes, if they are needed

I think I'm done for now? Hopes everything works.

Did you see TCQian.md?

May need to align capitalization?

Would it be better to put INDEX1 and INDEX2 as code (i.e. in ``)

May quote INDEX as code

May quote 'list' as code?

deadline number may be changed? e.g. deadline datetime

Similar as above

This may need to be changed?

I can see that all your code works. But would it be easier if we use java LocalDate and LocalDateTime to deal with it? And it may be easier for us in the future work if we want to filter projects by deadline.

All the examples may need to updated according to the validation regex.

This file may need to be changed (for deadline regex)

I think we'd better keep the format aligned, say use DEADLINE_DESC_AMY as the name. And we can change AMY to project names together for future refactoring work.

Same as the above comments about naming

Same as above comments about naming.

This is an email address rather than a repo address right?

i think this is ok but we should have a command to edit start and end date within travel plan directory also if not it might be a bit confusing

can change person to activity

rename p to activity?

person to activity

AddressBook change to ActivityList?

addressbook change to activity list?

address book change to friend list?

Returns true?

AddressBook change to WishList?

change person to activity

person change to activity, addressbook change to wishlist

addressbook change to wishlist

think you accidentally added 'a'?

Also added delete command to user guide. Not sure why it wasn't there? Maybe got removed accidentally.

index.getOneBased() - 1 is just index.getZeroBased()?

what is this haha

toAdd is can get confusing here, consider another name (deletedRecipe/updatedRecipe/etc)?

Do we need PersonListCard.fxml?

What about recipes?

Might be good to add an example like you did with Item

your optimal size / an optimal size / the optimum size might be better

Should a TODO be placed here?

Might be good to have TODO here as well

my zheng in the filename is missing a g lmao

might want to update the png as well

same here

might want to update the commands

same here

I think for this, it could just be "User enters the required details" since implementation details are not needed for use cases

Same as the above. Instead of this, perhaps you could try "User requests to cancel the command"?

I think for this, it could just be "User enters the required details" since implementation/UI details are not needed for use cases.

Same as above. Perhaps you could try "User requests to cancel the command" instead?

I believe bullet points are required for indentation here as well.

Perhaps a new indentation would be good here?

is there a typo here?

Might be better to mention that this command deletes everything before and up to the given date. It may be misunderstood to just delete visits on that date itself.

What might this suppress warning be for?

There shouldn't be a space after the method name. Also, since this method deletes multiple visits, maybe calling it deleteVisits would be more suitable.

This functionality could perhaps be moved into the for loop above? Then there would not be a need for an additional ArrayList to keep track of the visits to be deleted.

argMultimap.getPreamble().isEmpty() should be !argMultimap.getPreamble().isEmpty(), otherwise the code fails.

Only this part causes errors; the other comments are queries/small formatting errors.

Yes, these methods should already be functional barring unforeseen bugs.

The method was added for the following reasons:

The Person and Visit classes both have these two methods in Model - getFiltered[x]List() and updateFiltered[x]List() where x is either of those classes. As the InfoHandler class requires the getFilteredLocationList(), I felt it was apt that updateFilteredLocationList() was added as well.
Also, the addLocation method in the ModelManager requires the updateFilteredLocationList() as well.

As for the test above, the function is required to be overwritten for the ModelStub to be created.

Issues

Format

When creating an issue, try to specify the part of the project the issue is meant to be working on by using square brackets in the title. If the issue does not specify anything, it is assumed to be implementation-based, i.e., related to modifying AB3/VirusTracker code.

Example: [DG] Add UC01 and UC02 indicates that this issue works on adding user cases 01 and 02 to the developer guide.

Labeling

Mandatory label:

priority.* Indicates the priority level of the task. Has three levels, low, medium and high.

Apart from the mandatory priority label, you may include other labels to make it easier to search and locate issues. Feel free to add any labels, but please ensure no similar label already exists.

Pull Requests

General note: PRs can only be merged only when two or more other people have reviewed and approved of the merge.

Format for PR

When creating the PR, please state which issues the PR closes on the last line of the description.

Commit message: 'keyword #xx, keyword #yy, keyword #zz' for multiple issues

'keyword' refers to any one of the following three words, 'close', 'fix', 'resolve'.
- Using these keywords will cause the issue to be automatically closed once the PR is merged successfully.
- _Note: Other tenses for the above words could be used as well, such as 'closes' or 'closed', but let us standardise using the
  
  imperative form of the words above._
'#xx' references the issue number, where xx is the number. For example, xx = 10 will reference issue number 10.

Example: xx = 30

'''

...PR description here

Close #xx

'''

The above will close issue 30 upon the successful merging of the PR.

The actual form of #xx is not used in this comment as it would reference actual issues. Please refer to the PRs page for more examples.

The user cases have been added, and this issue will be closed

This user story has been added, and this issue will be closed.

Location classes have been completed, statistics classes will be moved to v1.2.

A new LocationHandler class should be created to be in charge of handling the statistics.

I've updated the title accordingly to avoid confusion

Rather than LocationHandler, we can instead create an InfoHandler class which additionally handles people and visits

Since ParserUtil.java is still there, is it better to keep this test file instead of deleting it?

What's wrong with this test

Does the position of the unnamed parameter matter?

How does the program behave towards these commands:

edit -n JohnDoe 1

edit1 -n JohnDoe

Just to justify my curiosity, can a command have multiple unnamed parameters?

I think this should be AddCommand.COMMAND_WORD instead of "add", the same for other commands

Although these test classes will be changed in McGymmy, is it better to keep them just for this PR to make sure that the new parser is working properly with the old AddressBook test first?

Same comment as AddCommandTest.java

Maybe add some more tests for the old address book's logic, to make sure that it works exactly as expected as the old parser?

I think naming it toString is enough

I think naming it getCalories is enough

object equality is intended, as I was checking if fridge and expected fridge contains the same elements. I have overridden the equals method for fridge class

Ok I will change it that way

Oops, I forgot to implement it. I will implement it in the next commits

Ok I will change it

I think we should keep it that way to prevent potential typos. Instead of that, we can add a comment at the end of the line to explicitly state what Carbohydrate.class.getName() is

I was just changing the name of the class. I haven't changed any of its implementations.

Ok I will change it

Fixed

Actually, we cannot call this.class before the object is initiated. Therefore, this.class.getName() cannot be put in either Macronutrient's constructor or a static method.

I think one alternate option is that we can use this.class.getName() as a replacement for the macronutrientType attribute

Got it!

Fixed

LGTM.

The CI test says that you are missing the shadow plugins

I think your use case have the same id as sean's.

LGTM.

Should we keep this?

maybe, coming in mid-v1.2? 😄

Don't remove this part. It is used by Jekyll

Perhaps, if you add this then we will have double title on the page (?)

Is this more of a "List a Client" use case?

'''suggestion

FitEgo adds the Client

'''

I'm not too sure if there is a timestamp in the status bar 😅 , but it is also in the AB3 DG ...

'''suggestion

  Expected: First contact is added to the list. Details of the added contact shown in the status message. Timestamp in the status bar is updated.

'''

'''suggestion

FitEgo displays the client's whose name matches the keyword or text.

'''

I see similar issues in other place as well

Perhaps its better to move this to ViewClientCommand::execute?

as to maintain separation between Ui and Logic components?

I agree with Dhafin.

i think in a javascript world, it is called a callback.

Perhaps hasCallback and getCallback is a better name?

Sounds good!

[open for discussion] Is it better to do the new way or the previous way?

This change is related to changes in SessionBuilder::withInterval

cc @maguireong @dhafinrazaq

Oh okay, i think I'll change it to only allow for the case where

cannot start or end with -
allow multiple - usecases

Oh right, I'll make it private

I think it is better to keep the structure of AB3 UG for future reference

donee

Proposed changes: show the number of clients inside the UI

TODO:

Repurpose the tag to history of injury / allergies
Change test data to medical names

Done for v1.1. Closing..

@dhafinrazaq @maguireong can help to look at it?

@tanweijie123 will this change be compatible with the change you proposed for #68 ?

Btw, perhaps it is better to test for checkstyle locally before pushing?

To run checkstyle and test cases, run ./gradlew check from Intellij terminal

To edit your last commit (so as to clutter the commit history), do git commit --amend --no-edit (also in terminal)

Would it be better if there was no need to generate default serial number here? As I feel it is an extra step before we get the actual serial number for the stock. I may have an idea of how to do it, and can help to work on it!

Perhaps could remove this line as it seems it is not relevant!

Perhaps it is not needed to show the path to the serial number sets book?

This line is pretty long. Perhaps could break it down to improve code readability?

Perhaps could break down into more readable statements. Seen a few times!

As mentioned, perhaps it is possible to remove this method!

Perhaps could make a new exception class for the duplicate source?

Perhaps "stock" should be "serial number set"?

Should "inputted" be "input" instead?

Should this line follow the format of the others such as what is shown in "status message"?

Should we standardise past tense / present tense? ("Update" vs "Added")

Based on our last meeting, I think prefix for quantity to increment/decrement should be changed to "iq/"?

I agree!

Thanks! Have done so in newest commit.

Maybe we can have an enum for TAB_ID instead to make it more clear.

Will it be confusing to have TAB_ID in Command.java and tabId in CommandResult.java? Maybe more descriptive name like tabIdToSwitchTo can help.

Should the command word be 'add' or 'add patient'? Since we've changed the AddCommand to AddPatientCommand, and we need to consider adding appointments too.

Should rename 'Person' to 'Patient' (but I think this is model people's job)

Since AddCommand was changed to AddPatientCommand, maybe ClearCommand should be changed to be more descriptive also? i.e. change to ClearAllPatientsCommand.

Formatting issues, can put on the same line.

I can't add a comment at the required line, but maybe we can rename this command to EditPatientCommand instead to align with AddPatientCommand? Also because we are probably adding capabilities or editing appointments right, so will need to clarify what we're editing.

Will also need to remember to edit the MESSAGE_USAGE to reflect patient parameters.

Likewise, should we rename to FindPatientCommand?

Likewise, should we change this to ListPatientsCommand? I'm not very sure because then now we'll have the 'Patient' in every command which is a lot more verbose, but it also makes the command clearer.

Why is PREFIX_REMARK removed?

Maybe we should have RemarkCommand for both patient and appointment? so we split into RemarkPatientCommand and RemarkAppointmentCommand

I think should be fine since all the CS modules we are covering follows that format. Or should we limit to 7 characters?

'''suggestion

 * Returns the user prefs' GradPad file path.

'''

can try using replace tool to search for remaining address book

I guess the Tag can be the Core and Non-core for now

'''suggestion

    // ensures that outOfBoundIndex is still in bounds of GradPad list

'''

'''suggestion

    // edit module in filtered list into a duplicate in GradPad

'''

'''suggestion

 * but smaller than size of GradPad

'''

'''suggestion

    // ensures that outOfBoundIndex is still in bounds of GradPad list

'''

'''suggestion

public void execute_multipleKeywords_multipleModulesFound() {

'''

'''suggestion

public void execute_zeroKeywords_noModuleFound() {

'''

'''suggestion

A utility class to help with building EditModuleDescriptor objects.

'''

'''suggestion

 * Parses the {@code tags} into a {@code Set<tag cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf">} and set it to the {@code EditModuleDescriptor}

'''

'''suggestion

 * Returns an add command string for adding the {@code module}.

'''

Not sure if that will affect the storage part but okay I'll change it first

I have changed it to CS2103T instead and passed the test case.

Oh okay yeah sounds good.

Yeap okay that one passed the test. But yeah was slightly confused with this test case.

Perhaps "DOB must not be a date in the future" will be better and more succinct?

Perhaps it is better to name it VALID_DATE_OF_BIRTH_AMY and VALID_DATE_OF_BIRTH_BOB to keep it consistent with the current style, where the full class name is used instead of abbreviations?

Perhaps it is better to name it DATE_OF_BIRTH_DESC_AMY and DATE_OF_BIRTH_DESC_BOB?

Maybe it is better to use the full class name for clarity?

A good case of invalid check since '/' is quite a common way of inputting dates.

Might have added 12 spaces instead of 8 by mistake?

Maybe you can re-arrange the order of the fields to make it more consistent with the rest of the code

Fixed

Perhaps it is better to have the first sentence of a javadoc on a single line.

Perhaps it is better to have these fields as private and provide getters for encapsulation purposes.

Perhaps it is better to define these variables as named constants (private static final) at the class level.

I have tried appending the commend to the end of the line, but the line will exceed 120 chars. Hence, I moved it to the top.

Thank you for pointing that out. I have added it into the check.

Completed fields necessary for v1.1

this should be email address

should the repository link in line 11 be changed as well?

might be more intuitive if the variable name is the same as the task name?

this function works in Tr4cker too. maybe we should keep the corresponding version of this line?

this might be an extra line

might want to surround the "prepare for tp tasks" with quotation marks

may want to keep the t in task as lowercase

should this keep the private access, and methods that use this call fromZeroBased(int) or fromOneBased(int) ?

would it be better to wrap the date time inside deadline with another class. so that we can just .dateTime instead of calling toString()

could name it MESSAGE_FUTURE_CONSTRAINS to be clearer

could these 2 if blocks be abstracted out? perhaps a method to check if the dayOfDeadline is contained inside the hashmap

if ur checking separately for TODAY, perhaps TODAY does not need to be inside the hashmap?

Merged #19

Merged #12

Minor edit listmodules

Delete this "<<<<<<< HEAD"?

Delete this too

Should we add in a case for invalid week specified by the user as an extension to [1]? Like week 123 or week -1. Same thing for UC03 - editing a task.

Perhaps we should add an extension for the case when a user inputs a module code that's not in the list? Like what you did for UC07.

See #62 from Hans, he included a numbering scheme for the features like 4.1.1, 4.1.2, etc. I think you can edit this section after his PR is merged into master.

I think you're missing a quotation mark at the end here.

I think we need a additional section below every "Format" to tell the user to reference the command parameters. For example:

ℹ️ | Refer to Section 4.1.1, “Service Management Command Parameters” for more detail about each parameter.

-- | --

And replicate this 'success' for the other parts till 4.1.7 😄

Can refer to @galvinleow 's PR for this ^.

4.1.1 should be on the same level as 4.1.2. Should we reduce the heading level for the commands below from #### to ### to match this?

Resolved!

Resolved 😃

Looks good to merge 😃

Resolved Merge Conflict in User Guide. Needs further edits to UG, but let's merge first @yanlynnnnn got issues.

Closing this PR as the Remark command feature will not be added for now. If so, this PR may be reopened in the future.

Numbering scheme will be relegated to v1.4

Also need to standardize the heading level, like ###, ##, etc.

Resolved, removed the additional Date class.

Perhaps change the name of the class to Session

Will we support delete+?

Perhaps can change this variable name to tab?

Perhaps you can make use of your Enum here?

private static final int CLASS_TAB = Tab.CLASSES.getValue();

Perhaps you can add in your public static final int value here.

'''

public enum Tab {

CLASSES(0),

ATTENDANCE(1)



private final int value;

Tab(int value) {

    this.value = value;

}



public int getValue() {

    this.value;

}

}

'''

Would it be a better design?

Perhaps missing a fullstop?

Perhaps "Constructs a {@code SessionDate}" ?

Perhaps "Standardizes" instead of "Standardize"?

Is there a missing space between RunTimeException and "{}"?

Awesome!

Sure thing!

Ahhh I see, thanks!

Yes there should be. Missed it out.

This was left with the intention of easy deleting if there comes an error.

Ahh I see. Thanks!

Thank you for the comment, I have resolved it!

Changed according to comments

28/9/2020 - still lacking test cases.

Minor error in checkstyle after resolving merge conflict, resolved in PR #90

Went ahead with Sheng Yang's version in PR #64 .

I don't think this line need to add UC2?

Might be better to change it to:

McGymmy shows a list of food in the database.

List of Food that user has added works too

LGTM

Just curious, what does this affect for the main page?

It kinda looks like a link to the repo like github.com/se-edu/addressbook-level3 and github.com/AY2021S1-CS2103T-W17-3/tp

Yes need the space after the ##

Might want to change this to a constant?

Like VALID_NAME_AMY, similar to the one u did in edit command test

Ookie in that case LTGM

I think we should use this.class.getName() instead and put it in the Macronutrient class and use it for each of the food items?

Might be able to clear up quite a few of the other assertions and methods mentioned below in Macronutrient

https://www.tutorialspoint.com/java/lang/class_getname.htm

Might not need this if we can get the nutrient type using the method mentioned in Carbohydrates.

This link might need to be changed in the future

Might be better to remove for now?

Might be better to put it into a method rather than just declaring

Can use @Before to initialise the fridge to reduce the complexity of layering the different test cases on top of one another (This might help if we decide to change/add more test cases in the future)

@Before

public void beforeEachTestMethod() {

    System.out.println("Invoked before each test method");

}

Might wanna remove this whitespace for consistency

Tags and Addr not implemented as they will be removed by the end of the iteration

Will removing the "find Grab" example make the table look neater?

Are we missing the details for adding an expenditure?

Perhaps "Temasek Hall" is too specific to NUS? Users who are not from NUS may not understand what it means. "Daily Expenses" might be a better example. I noticed the same issue in several other places.

Will it be more concise to use "budget" instead of "budget book"? I noticed the same issue in several other places.

Will it be better if "must be a positive integer" is bolded to draw users' attention to this restriction?

Same issue as above regarding the bolding of "must be a positive integer or double with a maximum of 2 decimal places". There seems to be two spaces between "of" and "2".

Same issue as above.

Perhaps it might be more cohesive to capitalise "school fees"? I noticed the same issue in several other places.

Yup, let's use "budget" instead of "budget book" as discussed. Good catch 👍

There is a missing space between the and LogicManager.java.

Perhaps DevOps should be separated with a white space to follow the title?

If you want, you can re-upload your photo so that it scales correctly. @sogggy

The examples for adding an expenditure is not in the correct format.

I interpreted step 2 as confirmation message (success message); is this what you intended? To redirect to 2 if there is incorrect input?

(Because the google docs says resume at step 1)

Applies to all the other use cases too

Javadocs to be updated {@code Person}

Same for this, perhaps this is MESSAGE_DUPLICATE_GROUP?

Is this to check whether PREFIX_PATH is present?

Should this be removed?

Modify javadocs

Are you calling Serenity() ? (empty constructor)

Empty constructor

This feels very similar to equals()

This cannot be deleted (their requirements)

This too

Should we use Index to select the book instead of the name of the book? Since the delete command already makes use of Index and using bookname is quite prone to typos

The user guide link is wrong, the correct link should be https://ay2021s1-cs2103t-f13-2.github.io/tp/UserGuide.html

Same for the dev guide as well, correct link should be https://ay2021s1-cs2103t-f13-2.github.io/tp/DeveloperGuide.html

I think you may have missed out on this part. The View command is meant to view detailed info regarding a single book.

I think this extension 2a isn't supposed to be here anymore, its included in UC05 already.

Just saw that the extension numbering here is incorrect, should be 2a, 2a1, 2b etc. Can you help change them too 🙏 thanks!

According to the user guide, the prefix should be "tp/" for total pages and "b/" for bookmark for consistency purposes right? Maybe we can discuss this further!

Thanks for doing the renaming! There's some parts which haven't been renamed such as the Javadoc here, comments in the equals() test as well as here: https://github.com/AY2021S1-CS2103T-F13-2/tp/blob/c568a3c5177c68a33c3e6279923fa8f3c0356df0/src/test/java/seedu/bookmark/logic/commands/AddCommandTest.java#L153

Would be great if you could change those too, thanks!

Could you edit the javadoc and comments as well please, thanks!

I think this line can be removed since the tests have been updated.

Could you update the tests names as well

LGTM

@mgiang2015 you uploaded your photo in the wrong folder, it should be uploaded in docs/images. Please open another PR to close this issue! 🙏

LGTM!

LGTM

Closed by #63

Reopening as @mgiang2015 's part on user stories for the View command is not done yet

Closed by PR #88

Good point, we'll do that in the next PR!

Agreed!

Agreed

Appointment class already has a String description, is that good enough?

Sorry, can you explain what is the TAB_ID used for in the Command class actually? Is it only relevant in the CommandResult class?

TAB_ID needs to be declared as a public static final constant above right?

Agreed! I think it will be addpatient based on our user guide.

I think so, because we will have various ListAppointmentsCommands, like listing all appointment of a specific patient!

Actually, I think it might be good to use the shorter versions? More user-friendly! We can update the UG to reflect this if everyone agrees

I think we can remove this line since Address field has been removed!

Should we remove the PREFIX_ADDRESS since we are no longer using Address?

you forgot to change the prefix, i think it should be type:

I dont think addressbook should be changed to typebook

This one also, should not change addressbook to typebook

this one also, should not change

this should be dateTime

Should be "constructs an empty DateTime when user does not provide the dateTime field

comment should be dateTime

Comment should be invalid dateTime

this comment also

should DEFAULT_DATE_TIME

should be dateTime instead of Phone

For use cases for list, add, delete, it should be task not person.

Do we have to do com.eva.storage.StorageManagerTest

Should this be com.eva.Model#getAddressBook instead

I think same issue as above, no need "CliSyntax" since it is imported already

Same issue here as above

Do you want to change the name of Comments to something like CommentList so that it is more clear that this is a list of comments

I think you need to change the javadocs here

Was thinking if this can be given a more informative name like startDate

same for 'to' maybe endDate

Was thinking if this can be improved to maintain the same level of abstraction as before, by constructing the Leave object with public Leave(LocalDate from, LocalDate to) because in other cases for example,

Add Person, the text input goes from Logic --> AddressBookParser --> AddCommandParser and this is where the Name, Email, Address Objects are made, then these objects are passed into AddCommand and is then passed into Model to add the person.

I think this change does not make a difference logic wise, but helps make the level of abstraction more standard. But up to you to take it up.

Alright sure, I agree with your reasoning, Thank you! Great job 😃

LGTM!

LGTM! Just one small comment. I think we can just stick to dates first? Or do you guys want to include timings as well.

Yeah, I think we can stick to dates first and build upon timings at a later stage.

Ah that one is LICENSE, should stay as person

@throws ParseException if the given {@code academicYear} is invalid.

@yejiadong @kerkpy

just need newline at EOF

HHmm instead? Capital M is for month i think

An UI component that displays information of a ...

{@code Training} ?

{@code TrainingSession} ?

{@code TrainingSchedule} ?

Panel containing the list of training/training sessions/training schedules.

Just putting a note here for myself

I personally think removeAllTraining() or clearTraining() would be more coherent with the removeTraining method above, in terms of naming. It's more of an opinion only so you still make the final decision

Added that to prevent over-coupling with the parser (wanted to make PredicateList more stand-alone)

tp.do();

My bad, didn't open to reviews

Gonna merge

LGTM!

I think that to match prefix, the e.g. would be sth like list l/people, list /stats. Please check on this.

Might want to refer to this as Virus Tracker instead of AddressBook.

Might consider changing to 'Clears all entries from Virus Tracker' to match description in line 42.

It appears that you have added some new functionality here regarding some statistics. Can these be used already?

Considering the nature of this test, it might be best that the method updateFilteredLocationList is completely removed from the working program since it is not expected to be called.

Additionally, on this aspect, I realised that updateFilteredLocationList is a method newly added to Model and ModelManager. Considering that, may I check why is the method added if it is not intended to be called as seen from this test?

I understand now. Thank you for the clarification.

To keep the code clean, I feel that this line should either be uncommented or removed.

Ids are abstracted away from the user. Users should not be aware of Ids, and thus should not be given the opportunity to change the id of a person. I feel that thus editpersondescriptor should not have an id field and id is automatically retrieved from the person that is being edited.

Some additional tests can be conducted in this class. Such as tests for adding unidentifiable locations and tests for setting location lists which dont fulfill the identifiable property. You may refer to #118 UniqueLocationListTest for reference.

Spelling error is intentional for the invalid person.

isnt this repeated with #19?

isnt this repeated with #18?

Pull Request Approval:

Before approving any pull requests, please ensure the following is done.

Eyeballing the code for any possible logic or other errors. This is also to familiarise yourself with implementation of the system.
Pull the pull request down into a local branch and give the features a test run. This is to check whether it actually works since eyeballing code may not be fool proof in ensuring functionality.

In addition, you might want to update the details of the pull request if it does indeed include some functionality involving the daily statistics. This is on the assumption that it is included.

Should this be Hall-y instead of AddressBook? Also, should it be hall admin (according to the use cases) instead of hall leader? Similarly for the rest of the terms below.

Should it be 'enters' instead?

Hmm seems like there was an issue with Git. Could you keep the original line under 'Saving the Data'?

Also, could you update the command summary at the bottom of the UG as well?

Should it be just 'in Hall-y', instead of 'in the Hall-y'?

Should it be resident instead of person?

Should this be a resident instead of a person?

Nice! @schoolex can refer to this for #37 when implementing the CLISyntax.

Should this be a series of instructions instead of a tip?

i.e. something like the edit command in the UG:

GENDER: must be either M or F
ROOM_NUMBER: must be <block cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf">_<room Number cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf">

Should there be a space after the commas?

Should it be 'listing all residents' instead?

Hmm the old link generates a badge though. Using /actions/ doesn't generate a badge, but a link instead...

Ohh I see. Sorry I misunderstood that.

Closing this, since it is part of the tutorial. Will not be merging unless we decide to drop address.

Closing this, since it is part of the tutorial. Will not be merging unless we decide to add Remark.

Need to verify if the tP tracker will still pick this up if the PR is closed. Do reopen if the tP tracker requires the PR to be open for grading.

Closing since AB3 already implements this feature. Do make sure if that the feature works with the updates to #10.

Remove from milestone v1.2. Will consider adding this into milestone v1.3.

Oops I missed this out: could you also update the command summary section for the edit command too?

PR closed as I messed up Git. 😢

Closing this, since it is part of the tutorial. Will not be merging unless we decide to add Remark.

Not sure why the badge doesn't load when it's first loaded, but after refreshing, it loads? 😕

Closing. Has been completed.

I don't think we can change the copyright license?

Abit hard to look through all without stepping through 😕

Was thinking of letting it merge and we test; but see the rest

NonExistenceFile.json is assertFalse for every src/test/data/* folder.

I guess it is a bug output file since the test doesn't want it to exist.

to fix this issue (change Clients to client), refer to the new comment

From what I found out:

The program uses the "Clients" variable as keyword to save a json file.
The program then uses @JsonProperty("clients") to pick this keyword for assignment from the json file

change @JsonProperty("Clients") to @JsonProperty("clients")

Yes. I expect it to have more errors.

Because, the actual data file is saved as caps Client instead of client.

I can only help u find these (those files in /JsonAddressBookStorageTest & /JsonSeralizedAddressBookTest) files, that you might be likely to change them from caps C to small C. Maybe there are others that are not flagged out

I think we should merge with the 2 test failure and create a new issue tracker to debug. Then can find out the root cause and more people can debug it instead of predicting the problem.

It seems to happen during the execution of saving a new temp file + reading failure.

This will allow the user to start and end with '-'

Not sure if that was intended.

If it was correct, try to add 1 test case to test it 😄

My DateTime formatter also different from yours

DateTimeFormatter.ofPattern("dd/MM/yyyy HHmm")

Maybe can do if (sessionId == null || !ParserUtil.tryParseInt(sessionId)) , then throw IllegalValueExcep

The will set it as tab name, while the # About Us is the in the webpage.

Yes. I agree with you, but UI cannot run test cases.

Putting it in ViewClientCommand cannot test execute.

Usually, it should be placed in MainWindow::executeCommand, but I will see how

Edit: ViewClientCommand will create a lambda runnable for MainWindow to run.

Updated

fixes #18

similar to #41

@tanweijie123 will this change be compatible with the change you proposed for #68 ?

Yes. All the test case refactoring can be used. (because I have not started with that)

Gym, Interval, ExerciseType can be imported because currently, I am using it as String type

We can merge the Session to accommodate with ^.

Can refer to #70

#68

fixes #78

Right sidebar previously had a scrollbar that doesn't show now, but I think it's fine not to have it. Lgtm!

Vbox have auto hide scrollbar if not necessary. So maybe your screen size bigger?

maybe we should include the brand of the milk tea shop here also? as some function are only for TGER SUGER brand

I think we should still use this prefix, to distinguish the input is either a name or a tag or something else.

Same applies to below, line 57

there is a white space before "ingredient", I think it should be a typo and need to be removed?

Maybe can consider to shift this point up, can put after the first point? It flows more naturally.
Maybe the second sentence can change to something like this? -> "This application is tailor-made for bubble tea shop managers, to help them on store management."

Maybe can write down the full name for CLI (Command Line Interface)? In case some users don't know what CLI stands for.

Maybe can consider to shift this row up to line 265? so that we can group all priority 1 & 2 together

I think we should still use this prefix ("n/", "p/", etc), to distinguish the input is either a name or a tag or something else.

Yup, should keep both. "e/" for emergency contact, "p/" for employee's contact number.

I'm not sure if "set" is a prefix and need to add into here. Based on my understanding, we only need to add new prefix when we need to create a new field in a person model. Like if we create a field to record remarks, then we need to add "r/" as a prefix. But "set" does not function in this way. When user key in "set ...", then program will execute the "set", not to add the values behind to a field.

Please correct me if I'm wrong, thanks 😃

Maybe you could consider using case structure here? It looks clearer, but if is working perfectly. 👍

Good point! Resolved, thanks (:

Removed. Thanks (:

Sure, just added. thanks

Good point, just added in. thanks

Okay, I've added that in. Thanks!

Thanks for pointing out! Will edit it and change it in the next iteration.

Thanks! I've changed that.

LGTM

If I'm not wrong the textbook didn't have these white spaces.

Same problem as above.

Can delete white space, seems unnecessary.

Delete this line, I think its from a merge conflict.

Delete this single white space.

Good that you have a separate class for Description, instead of a String.

Good that you have a Predicate class

Maybe, abstract away details, for better readability.

Can you just combine the two methods, seems like not much of a difference.

Abstract away to reduce complicated expressions

Okay I will change accordingly!

Hi, yes that's why I thought a PriorityQueue would lead to an easier implementation as we can determine its priority in the Room class and we don't have to individually compare details. If you really want an arraylist I can change it though.

It is to add the number of rooms into the hotel

It is to check for the empty room with the least ID number. So the first room, is the least number that is not occupied.

Or if it is occupied then every room is occupied.

I thought of that, but why would anyone want to input a negative number?

Yes, it is for future person assigned to this task to complete it.

but it passed checkstyle

I just followed the name of files given above.

Okay

I dont get your problem here.

It wont because 1 and 3 are stored in the hard disk

I think you are confused because they are methods in different classes, just like the original code.

yeap, im not responsible for tasks and adding person

okay sure ill add it

I thought AddRoom would be better suited for adding person to room.

Same reason stated above.

I'll change it if you want.

I removed that field.

okay

Can you clarify?

Actually I no longer have this.

I see a lot of you have a lot of questions on PQ. I just thought that the comparison would be simpler as the priority is maintained by the PQ, and all we have to do is to poll and we dont have to compare a lot of variables so fewer bugs.

Yes

Okay, will add!

Okay

I need it for the Json.

Okay will do!

Okay

That was wat I was wondering too, but didn't want to delete before discussing.

I suggest changing this to .png according to the specifications. Similarly, change to file itself to .png too.

Perhaps "Expiry dates should be of the format d-MM-yyyy, dd-MM-yyyy, d/MM/yyyy or dd/MM/yyyy." might be more accurate?

Very minor, should be "an" instead of "a".

Nice touch to order alphabetically.

This should be "Returns true if a given string is a valid priority level"

A little odd to change to lower case before validation checks. Maybe only do so in line 30 (i.e. switch(priority.toLowerCase())?

Just to standardize with the other fields: "Priorities should be either high, medium or low.";

Perhaps you can consider using a switch statement? Just a suggestion.

I understand, you are converting the input to lower case then performing validation checks on them. Then there is no need to change.

Yes this step is redundant

I believe the definition here is required, since use cases have System and Actor(s), here we say we are using SimplyKitchen to represent our System.

Good catch!

Sure thing, I'll make the changes.

I see. I will leave these sections to be updated as the diagrams require changing in the future too.

Good catch

Thanks!

LGTM

LGTM!

I think it would be good to standardise. LGTM other than this.

Are we going to allow the new quantity to be less than 0?

Where do you suggest then? The other location I can think of is stock class.

Is there an extra tab here?

I think you shouldn't use the short form of accumulated here for the class name?

I think this is fine.

Should we include an example which shows the usage of deleting multiple stock?

Maybe can include the word "multiple" to make the use case more explicit? Some people with poor English like me might miss this out.

just a small typo here I chanced upon

Nope. I think the refactoring screwed up all the links within the docs. Good catch!

We would be storing stocks rather than person in our warenager so I thought the renaming of the class would be appropriate here.

LGTM!

LGTM

update sn/fairprice1 iq/1000 sn/fairprice2 seems to be incrementing both stock by 1000. Is this the expected behavior?

To check with prof regarding the changes to be made to monitor code coverage

Minor issue, remember to capitalize Supplier and line 276 and 280 as well.

Same issue, minor typo for Supplier

Capitalize also

Similar to comments left on UniqueWarehouseList, should this be removed instead?

Similar to comments left on UniqueWarehouseList, might want to change to replaceSupplier

Minor issue, capitalise Suppliers

Capitalise Suppliers here

Approve for testing purpose to see the badge shows CI fail

Test successful, icon changed to failing.

@zhengweii Revert back to pass CI